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EXECUTIVE  SUMMARY 


Integrated  Product  Development  (IPD)  is  an  efficient  process  of  bringing  a  product  from  user’s 
needs  to  field  operation.  The  basic  principle  is  to  iterate  and  integrate  the  design  of  a  product  and 
the  design  of  its  manufacturing,  operation,  support  and  training  processes  with  specific  focus  on 
achieving  low-cost  development,  production,  operations  and  support  within  the  shortest  schedule 
while  achieving  robust  quality  of  the  products  and  services.  The  IPD  approach  requires  the 
simultaneous  and  integrated  development  and  qualification  of  all  the  elements  of  a  total  system  as 
contrasted  to  a  sequential  development  process.  It  focuses  on  establishing  Integrated  Product 
Teams  at  the  “doing  level”  to  ensure  that  all  functional  and  special  interest  groups  are  “integral 
contributors”  rather  than  “monitors”  in  the  process.  For  IPD  to  be  successful,  the  development 
process  must  change  what  people  do,  and  when  they  do  it,  so  that  they  actively  participate  by 
creating  products  that  incrementally  define  the  total  system.  IPD  increases  the  focus  on,  and 
“ownership”  of,  the  products  and  processes,  improves  horizonal  communications,  establishes  clear 
lines  of  responsibility,  delegates  authority,  establishes  clear  interfaces  with  industry,  and  changes 
the  acquisition  process  expectations  so  that  the  activities  and  success  criteria  are  based  on  the  total 
product  including  its  manufacturing,  support  and  training. 
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1.0  BACKGROUND 


Significant  contributions  were  made  by 
industry  in  identifying  barriers  in  the  acquisition 

The  benefits  of  Integrated  Product  Develop-  process  and  in  making  recommendations  for 

ment  (DPD)  have  been  convincingly  demon-  improvement.6 
strated  in  many  commercial  applications.1  Aero¬ 
space  industry  has  also  been  changing  and  sig¬ 
nificant  progress  has  already  been  demonstrated? 

Since  implementation  of  IPD  will  take  place 
principally  in  industry,  the  best  mechanisms  for 
helping  industry  are  to  remove  the  inhibitors  in 
the  acquisition  process  and  to  provide  leadership 
in  accelerating  the  adoption  and  advancement  of 
IPD  practices  and  methodologies. 3  In  fact,  the 
aerospace  industry  has  stated  that  the  govern¬ 
ment  must  change  the  acquisition  process  for 
them  to  be  totally  successful. 

Dr  Robert  Costello,  while  DOD  Undersec¬ 
retary  of  Defense  for  Acquisition,  recognized 
the  importance  and  potential  of  the  IPD  concepts 
to  DOD  acquisitions  and  required  the  services  to 
begin  implementation.4  Also  recognizing  the 
significance  of  the  concept,  former  ASD  Com¬ 
mander,  Lt  Gen  Loh,  established  a  Critical  Proc¬ 
ess  Team  (CPT)  on  IPD  as  a  Total  Quality  initia¬ 
tive  to  create  a  culture  to  integrate  the  IPD 
concepts  into  the  acquisition  process.5  The  team 
was  tasked  to  define  and  recommend:  (1)  inte¬ 
grated  development  and  integrated  management 
processes  for  the  concurrent  design  and  verifica¬ 
tion  of  products  and  their  manufacturing  and 
support  processes;  (2)  a  process  for  improving 
technology  transition  as  it  relates  to  IPD;  and  (3) 
incentives  for  industry  to  embrace  IPD. 

This  document  captures  the  results  of  the 
CPT  and  recent  efforts  to  refine  guidelines  for  its 
implementation.  It  is  not  a  description  of  the  as- 
is  process  but  a  vision  of  the  to-be  process  de¬ 
scribed  at  an  intermediate  level  of  detail.  Its  pri¬ 
mary  purpose  is  to  provide  a  conceptual  frame¬ 
work  to  provoke  dialogue  that  will  lead  to  incre¬ 
mental  improvements  to  our  way  of  doing  busi¬ 
ness. 
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2.0  INTRODUCTION 

By  pursuing  an  approach  to  systems  acquisi¬ 
tion  called  “Integrated  Product  Development 
(EPD)”,  it  is  possible  to  increase  the  quality  of 
our  products  and  services,  reduce  costs,  and  de¬ 
crease  the  time  it  takes  to  get  new  systems  in  the 
hands  of  Air  Force  operational  users.  The  basic 
concept  of  IPD  is  to  move  towards  a  more  fully 
integrated  development  approach  as  shown  in 
Figure  1.  For  this  to  be  successful,  IPD  must 
change  what  people  do,  and  when  they  do  it,  so 
that  they  actively  participate  in  defining  and  de¬ 
veloping  the  total  product  including  its  manu¬ 
facturing,  training  and  support  requirements  and 
capabilities.  Such  objectives  are  not  new,  but 
have  in  some  cases  been  pursued  in  a  piecemeal 
fashion  by  functional  and  specialty  (“stovepipe”) 
organizations  who  compete  with  one  another  for 


resources,  top-management  “emphasis”  and  rec¬ 
ognition.  This  should  be  recognized  as  the 
advocacy  approach.  While  sometimes  achiev¬ 
ing  success  in  targeted  areas,  IPD  will  enhance 
our  chance  for  success  of  realizing  the  potential 
for  improvement  in  performance,  life  and  sup¬ 
port  characteristics,  reduced  life-cycle  cost,  and 
decreased  development  time.  We  will  strive  to 
achieve  these  objectives  simultaneously  by  inte¬ 
grating  the  diverse  specialty  functions  and  the 
people  associated  with  them  into  a  unified  de¬ 
velopment  process.  This  approach  places  in¬ 
creasing  emphasis  on  true  teamwork. 

IPD  brings  people  representing  different  func¬ 
tions  together  at  the  beginning  of  development 
to  work  as  equals  in  a  climate  of  trust  and 
ownership  to  incrementally  and  simultaneously 
refine  the  definition  of  the  total  product  includ- 
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ing  its  manufacturing,  training  and  support  ca¬ 
pabilities.  Figure  2  depicts  a  functional  architec¬ 
ture  for  this  process.  This  process  is  governed  by 
an  enhanced  product  definition  and  control  ef¬ 
fort  and  an  integrated  product  and  process  devel¬ 
opment  effort.  Each  of  these  enabling  efforts  are 
described  in  subsequent  paragraphs.  These 
efforts  are  supported  by  enabling  computer 
technologies  that  permit  the  use  of  digital  data, 
shared  common  data  bases,  3D-solid  modeling, 
computerized  mock-up  equivalents,  etc.,  to 
reduce  design  and  fabrication  times,  promote 
product  and  process  optimization,  and  improve 
the  quality  of  product  definition,  manufacturing, 
training  and  support  data.  This  is  inherently  a 
more  efficient  and  responsive  process. 

The  IPD  process  will  facilitate  the  manage¬ 
ment  of  change  and  help  the  integrated  product 


teams  solve  the  customers’  needs  by  permitting 
requirements,  technologies  and  product  devel¬ 
opment  to  co-evolve.  IPD  can  help  customers 
understand  the  subtleties  of  their  needs  and  the 
limits  of  technology  by  making  product  devel¬ 
opment  a  problem-solving  process  among  mul¬ 
tiple  customers  and  multiple  functional  experts 
working  as  a  team. 

End-users  involvement  throughout  the  proc¬ 
ess  is  crucial.  As  the  more  detailed  definition  of 
the  requirements  evolve  to  the  design  level, 
interpretation  and  selection  of  design  specifics 
among  alternatives  is  of  paramount  importance 
to  the  end  user's  eventual  satisfaction.  Thus,  the 
team  must  be  availed  to  the  user's  desire  of 
choice  and  priority  of  operation  throughout  the 
development  cycle.  Without  the  user's  involve¬ 
ment,  the  delivered  system  may  not  be  fully 
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useful  or  the  user  may  feel  a  lack  of  ownership. 
IPD  can  help  resolve  conflicts  in  meeting  the 
needs  of  a  wide  variety  of  customers  (operator, 
maintainer,  supporter,  trainer). 

Keys  to  success  for  most  development  proj¬ 
ects  lie  in  the  recognition  that  requirements, 
technology  and  expertise  co-evolve  and  in  the 
ability  to  balance  and  manage  issues  in  a  chang¬ 
ing  environment.  The  challenge  is  to  meet  the 
customers'  needs  for  a  wide  range  of  customers 
who  have  different  or  conflicting  requirements. 
These  needs  must  be  met  within  budget  and 
schedule  constraints,  and  include  planning  for 
anticipated  future  growth  through  flexible  prod¬ 
uct  designs,  manufacturing  processes  and  sup¬ 
port  processes. 
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3.0  PRODUCT  DEFINITION  AND  product  and  process  optimization.  This  is  true 
CONTROL  from  the  beginning  of  a  weapon  system  develop¬ 

ment;  therefore,  even  the  very  early  systems  en- 
3.1  Systems  Engineering  in  the  Acquisi-  gineering  efforts  include  all  elements  of  the 
tion  Process  “team”  expertise  e.g.  cost,  design,  manufactur¬ 

ing,  support, test,  etc.  All  members  of  the  team 
Systems  Engineering  is  the  function  that  work  from  a  common  baseline  and  trade  studies 
controls  the  evolution  of  an  integrated  and  opti-  address  all  the  critical  product/process  charac- 
mally  balanced  system  to  satisfy  customer  needs  teristics  of  the  area  being  studied, 

and  to  provide  the  data  and  products  required  to 

support  acquisition  management  decisions.  The  major  products  of  this  early  systems 
Systems  engineering  encompasses  the  complete,  engineering  effort  are  integrated  requirements, 
integrated  technical  effort  to  define,  design,  pro-  integrated  specifications,  interface  control  docu- 
duce,  verify  and  deploy  a  life  cycle  optimized  ments,  integrated  schedules  and  technical  budg- 
system.  In  the  process  shown  in  figure  3,  sys-  ets.  These  products  establish  the  “boundaries” 
terns  engineering  controls  the  entire  technical  for  the  efforts  of  “product”  oriented  integrated 
effort  to  develop  the  total  product  including  its  product  teams  (IPTs)  who  will  continue  to  use 
manufacturing,  training  and  support  .  Systems  the  systems  engineering  process  to  accomplish 
engineering  addresses  all  “critical”  characteris-  the  integrated  product  and  process  development 
tics  of  me  product  and  its  associated  manufac-  activities.  All  members  of  the  IPTs  must  em- 
turing,  training  and  support  in  order  to  achieve  brace  the  systems  engineering  approach. 
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-  Concept  Exploration  Phase- 

The  industry’s  systems  engineering  activity 
during  the  concept  exploration  phase  is  translat¬ 
ing  the  users'  needs  into  alternative  design  con¬ 
cepts,  through  functional  analysis,  synthesis, 
and  trade-off  analysis.  This  is  accomplished  by 
exploring  various  alternatives  to  satisfy  these 
needs,  defining  the  most  promising  system 
concept(s),  and  developing  supporting  analyses 
and  information  to  include  identifying  high  risk 
areas  and  risk  abatement  approaches. 

— Demonstration/Validation  Phase- 

The  objectives  of  the  Demonstration/Valida¬ 
tion  Phase  are  to  prove  that  technologies  and 
processes  critical  to  the  most  promising  system 
concept(s)  are  understood  and  attainable;  and  to 
better  define  the  critical  design  characteristics 
and  expected  capabilities  of  the  system 
concept(s).  System  level  requirements  are  de¬ 
fined  and  refined,  major  system  configurations 
are  identified  and  analyzed,  and  risk  abatement 
is  pursued  for  subsystems,  materials  and  manu¬ 
facturing  capabilities.  The  government  product 
of  this  phase  is  a  Systems  Requirements  Docu¬ 
ment.  This  document  does  not  constitute  selec¬ 
tion  of  a  specific  design,  but  rather  establishes 
system  level  requirements,  employment  and 
deployment  environments  and  constraints  and 
affordability  constraints  based  on  identification 
of  feasible,  affordable  ranges  of  cost  and  system 
effectiveness.  Proper  identification  of  require¬ 
ments,  in  performance  terms,  is  essential  to  an 
effective  acquisition  strategy  since  real  compe¬ 
tition  requires  a  System  Requirements  Docu¬ 
ment  which  can  be  met  by  more  than  one  design 
concept.  The  system  specification  is  used  by  the 
government  and  contractor  to  mutually  define, 
from  a  performance  perspective,  the  system  level 
operational  performance,  capability,  functional 
and  supportability  requirements  and  the  meth¬ 
ods  for  their  verification.  The  results  are  docu¬ 


mented  in  an  offeror  unique  system  specifica¬ 
tion  based  on  the  Air  Force  Guide  Specification 
(AFGS-87253). 

During  the  systems  engineering  synthesis, 
required  configuration  items  (CIs)  are  identi¬ 
fied.  The  process  includes  trade-off  analyses  to 
ensure  that  the  system  will  satisfy  the  develop¬ 
ment  specification  performance  requirements 
with  the  best  possible  balance  of  LCC,  schedule, 
system  effectiveness,  manufacturability,  and  sup- 
portability. 

Elements  of  the  proposed  system  are  continu¬ 
ally  assessed  to  identify  areas  of  technical  uncer¬ 
tainty  that  must  be  resolved  in  later  program 
phases  (risk  assessment).  Critical  components, 
manufacturing  processes,  and  training  and  sup¬ 
port  products  should  be  rapidly  prototyped  to  re¬ 
duce  risk.  At  the  end  of  the  D/V  phase  (or  early 
in  the  Engineering  and  Manufacturing  Develop¬ 
ment  phase)  agreement  is  reached  on  the  system 
level  requirements  and  the  major  configuration 
items  are  defined.  The  contractor  develops  a  set 
of  development  specifications  for  the  major 
configuration  items.  These  subsystem/equip¬ 
ment  development  specifications  are  written 
using  MIL-PRIME  development  specifications 
and  the  product  integrity  program  specifica¬ 
tions.8  The  MIL-PRIME  specifications  contain 
a  non-contractual  handbook  which  provides  ra¬ 
tionale,  guidance,  lessons  learned  and  instru¬ 
ments  necessary  to  tailor  the  requirements  and 
verification  sections  of  the  MIL-PRiME  speci¬ 
fication  for  a  specific  application.  As  such,  the 
system  and  subsystem  development  specifica¬ 
tions  provide  the  technical  management  frame¬ 
work  for  the  Government  and  Contractor  Inte¬ 


— Engineering  and  Manufacturing 
Development  Phase- 

The  purpose  of  the  Engineering  and  Manu- 


grated  Product  Teams. 
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factoring  Development  phase  is  to  complete  all 
the  activities  necessary  to  go  to  rate  production 
and  to  field  and  fully  support  the  system.  This  is 
done  by  completing  detailed  design  and  devel¬ 
opment  of  the  total  product  including  manufac¬ 
turing,  training  and  support,  and  demonstrating 
that  all  requirements  are  met.  The  Engineering 
and  Manufacturing  Development  design  activ¬ 
ity  is  based  on  development  specification  re¬ 
quirements  and  supporting  in-process  event-ori¬ 
ented  verifications  using  the  systems  engineer¬ 
ing  master  schedules  (SEMS).  (See  Section 
3.4.)  Risk  is  continually  assessed  using  the  tech¬ 
nical  performance  measurements,  SEMS  suc¬ 
cess  criteria,  and  cost/schedule  control  system 
criteria.  Integrated  Product  and  Process  Devel¬ 
opment  activities  are  the  primary  responsibility 
of  government  and  contractor  integrated  prod¬ 
uct  teams. 

Product  definition  and  control  activities  fo¬ 
cus  primarily  on  resolving  interface  compatibil¬ 
ity  problems  and  solving  technical  problems  dis¬ 
covered  during  development  testing,  manufac¬ 
turing  process  proofing  and  supportability  veri¬ 
fication  that  cut  across  team  boundaries.  Sys¬ 
tems  engineering  ensures  the  validation  of  the 
Build-to-Package,  Training  Package  and  Opera¬ 
tion,  Support  and  Maintenance  Package  docu¬ 
mentation.  A  description  of  these  packages  are 
contained  in  Section  4. 1 .  This  includes  verifica¬ 
tion  of  all  requirements  including  systems  safety 
and  systems  security,  and  completion  of  the  sub¬ 
system/system-level  verification  process. 

The  Engineering  and  Manufacturing  Devel¬ 
opment  phase  verifies  operational  effectiveness 
and  suitability  before  deployment  by  testing  the 
system  or  equipment  in  a  simulation  of  its  in¬ 
tended  operational  and  support  environment. 
Development  results  are  reviewed  to  confirm 
that  the  system  design  meets  the  "exit  criteria"  to 
proceed  with  production,  training  and  support 
activities  that  precede  operational  use.  The 
output  of  Engineering  and  Manufacturing  De¬ 


velopment  is  a  qualified  product  and  verified 
manufacturing,  training  and  support  processes 
that  consistently  yield  and  maintain  a  quality 
product  and  the  documentation  necessary  to 
enter  the  Production  and  Deployment  phase. 
The  documentation  includes  Build-to-Packages, 
Training  Packages  and  Operation,  Support  and 
Maintenance  Packages. 

Integrated  Product  Development  is  a  team 
activity  involving  engineering,  manufacturing, 
test,  configuration  management,  product  sup¬ 
port  and  business  customers  (the  user,  the  main- 
tainer,  the  trainer)  that  support  the  program  man¬ 
ager.  Achieving  the  desired  results  requires  a 
structured  process  and  teamwork  among  com¬ 
petent  people  with  specific  expertise  and  under¬ 
standing  of  the  product,  users,  technology  base, 
materials,  manufacturing  capabilities  and  re¬ 
quirements,  training  capabilities  and  require¬ 
ments,  support  capabilities  and  requirements 
and  the  acquisition  process. 

3.2  Translating  User  Needs  and  Establishing 
Integrated  Requirements 

A  major  responsibility  of  systems  engineer¬ 
ing  is  to  capture  the  “voice  of  the  customer”  in 
terms  that  the  integrated  product  team  can  un¬ 
derstand.  This  is  a  necessary,  but  difficult  proc¬ 
ess.  One  formal  technique  for  capturing  the 
“voice  of  the  customer”  and  mapping  them  into 
product  and  process  parameters  is  called  Quality 
Function  Deployment  (QFD).  It  consists  of 
techniques  for  creating  and  completing  a  series 
of  matrices  showing  the  association  between 
specific  features  of  a  product  and  needs  repre¬ 
senting  the  “voice  of  the  customer.”  QFD  uses 
teamwork,  creative  brainstorming  and  extensive 
customer  dialogue  to  identify  customer  needs 
and  design  parameters.  The  correlation  between 
the  needs  and  the  design  parameters  is  ranked 
and  normalized.  Parameters  of  comparable 
systems/subsystems  are  also  identified  and 
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ranked.  The  top-down  requirements  definition 
process  continues  as  functions,  subassemblies, 
parts,  failure  modes,  critical  manufacturing  steps, 
etc.  are  identified  and  traced  to  critical  customer 
needs  and  comparable  products  (or  predecessor 
systems).  Matrices  are  a  means  of  recording  the 
information  to  show  correlations.  If  the  cus¬ 
tomer  needs  are  the  rows  of  a  matrix  and  product 
features  are  the  columns,  it  is  possible  to  show 
positive  and  negative  correlations  among  the 
product  features  in  a  triangular  table  above  the 
matrix.  The  triangular  table  above  the  matrix 
resembles  a  roof,  hence  the  term  “house  of 
quality.”7  This  and  similar  techniques  have  been 
used  with  reported  advantages  of  significantly 
reducing  changes  as  a  design  enters  production 
and  decreasing  the  time  needed  to  get  a  design 
into  production. 

Requirements  must  be  translated  concurrently 
and  in  an  integrated  fashion  into  optimal  product 
definitions,  manufacturing  processes,  training 
processes  and  support  processes.  Systems  engi¬ 
neering  must  encourage  and,  in  fact,  ensure  that: 
( 1 )  all  requirements  of  the  life  cycle  are  consid¬ 
ered  and  evaluated;  (2)  the  cross-impact  of  vari¬ 
ous  functional  decisions  are  understood  and 
evaluated  with  appropriate  tradeoffs;  (3)  critical 
risks  of  various  design  options  are  identified  and 
addressed  early  in  the  process;and  (4)  those 
responsible  for  the  various  functional  areas 
participate  with  appropriate  levels  of  responsi¬ 
bility  and  authority. 

3.3  Integrated  Specifications 

DOD  has  given  top  priority  to  improvement 
in  performance,  capabilities  and  life  characteris¬ 
tics  of  its  systems/equipment.  Its  recent  ap¬ 
proach  to  obtaining  such  improvements  can  be 
called  "single  feature  improvement."  These 
single  features  are  referred  to  as  the  "ilities,"  e.g., 
reliability,  maintainability,  producibility,  sup- 
portability,  etc.  This  "ility"  approach  has  unfor¬ 


tunately  led  to  separate  advocates  or  specialty 
groups  with  separate  budgets.  This,  in  turn, 
caused  “stovepipe”  functional  activity  by  the 
contractors  as  well  as  the  govemment.Pursuing 
these  single  feature  improvement  objectives  in 
this  manner  has  led  to  a  cumbersome,  sequen¬ 
tial,  costly,  suboptimized  acquisition  process. 

Typically,  an  “ility”  is  institutionalized 
through  a  military  standard  and  contractually 
implemented  through  assigned  tasking  in  the 
statement  of  work  (SOW)  portion  of  the  con¬ 
tract.  It  has  an  associated  budget  and  requires 
delivery  of  a  product,  usually  a  report.  The  MIL- 
Standards  on  which  the  SOW  tasking  is  based 
describe  generalized  procedures  that  are  similar 
from  “ility”  to  “ility”  and  often  duplicative  (e.g., 
four  deliveries  of  Failure  Modes,  Effects  and 
Criticality  Analysis).  The  SOW  tasking  gener¬ 
ates  activity  that  is  indirectly  related  to  the  deri¬ 
vation  of  essential  product  characteristics. 

An  alternative  approach  is  to  define  the  prod¬ 
uct  characteristics  that  the  “ility”  seeks  to  influ¬ 
ence  and  include  them  in  the  specification.  The 
general  rule  should  be  that,  if  a  characteristic  is 
important,  then  it  should  be  in  the  specification. 
To  be  in  the  specification,  it  must  be  quantifiable 
(stated  in  performance  terms)  and  verifiable. 
This  approach  ensures  the  appropriate  top-down 
requirements  process  through  the  specification 
tree. 

The  growing  dependence  on  software  in  to¬ 
day’s  systems  poses  a  unique  challenge  to  sys¬ 
tems  engineering.  One  of  the  most  significant 
challenges  in  software  development  is  software 
requirements  definition  and  associated  require¬ 
ments  change  process.  Development  specifica¬ 
tions  will  address  the  total  system/equipment  re¬ 
quirements  including  hardware  and  software. 
Achieving  these  total  requirements  is  the  re¬ 
sponsibility  of  the  integrated  product  team.  The 
development  of  software  will  be  accomplished 
from  a  total  system  perspective  to  address  em- 
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bedded  software,  developmental  test  software, 
software  for  factory  test  equipment,  support  and 
test  equipment  software  and  training  equipment 
software. 


3.4  Performance  Based  Progress  Criteria 

The  Systems  Engineering  Master  Schedules 
(SEMS)  provide  a  tailored  package  of  tasks, 
schedules,  and  success  criteria  for  the  essential 
product  characteristics  in  each  of  the  specifica¬ 
tions  that  were  negotiated  between  the  program 
management  office  and  the  contractor.  These 
packages,  together  with  the  Statement  of  Work 
form  the  basis  for  the  System/Subsystem  Inte¬ 
grated  Master  Schedules  (SIMS).  The  SIMS 
contractually  identify  critical  development  and 
program  tasks  and  activities,  with  success  crite¬ 
ria,  that  must  be  completed  to  pass  identified 
program  milestones  and  subsystem  incremental 
reviews.  As  such,  the  SIMS  provide  the  basis  for 
developing  program  cost  and  schedules  as  well 
as  performance- based  progress  criteria  by  pro¬ 
viding  meaningful  measures  of  merit  to  track 
program  progress  and  system  operational  capa¬ 
bility  for  technical  and  business  management 
visibility.  The  agendas  of  all  program  reviews 
and  contract  progress  payments  should  be  based 
on  performance- based  progress  criteria  identi¬ 
fied  in  the  SIMS. 


on  system  effectiveness,  manufacturability  and 
operational  suitability.  This  technique  provides 
the  necessary  management  tools  to  put  disci¬ 
pline  into  the  integrated  product  development 
process  by  establishing  accountability  and  en¬ 
suring  management  involvement. 

Key  top  level  measures  of  success  in  imple¬ 
menting  the  integrated  product  development 
process  that  industry  6  has  found  helpful  are: 

•  Product  Cost  -  Target  cost  versus  current 
estimate  (Development,  Production,  Operation 
and  Support) 

•  Product  Quality  -  Process  performance  index 
or  first  pass  test  yields  (targets  versus  actual 
using  a  learning  curve) 

•  Product  Schedule  -  Total  time  versus  suc¬ 
cessful  completion  of  key  tasks  by  major  event 
milestones 

•  Implementation  Costs 

— Development  hours  (targets  versus  actu¬ 
als  or  current  estimates) 

—  Tooling  costs  (targets  versus  actuals  or 
current  estimates) 

—  Training  cost  per  student 
—  Support  cost  per  operational  unit 


r 


The  mutually-defined,  time-phased  event- 
driven  tasks  and  activities  contained  in  the  SIMS 
and  technical  performance  measurements  pro¬ 
vide  the  means  for  risk  assessment  of  contractor 
progress.  Technical  performance  measurement 
assesses  product  design  by  estimating  through 
engineering  analysis  and  tests  the  values  of  es¬ 
sential  specification  parameters  of  the  current 
design.  It  forecasts  the  values  to  be  achieved 
through  the  planned  technical  program  effort, 
measures  differences  between  the  achieved  val¬ 
ues  and  those  allocated  to  the  product  element, 
and  determines  the  impact  of  these  differences 


3.5  Integrated  Planning  and  Scheduling 

A  fundamental  change  to  planning  and  sched¬ 
uling  is  an  essential  part  of  the  integrated  prod¬ 
uct  development  process.  The  frequently  ob¬ 
served  practice  of  maintaining  separate  plans 
and  schedules  for  each  discipline  is  replaced  by 
a  single  integrated  schedule.  This  requires  more 
than  combining  all  existing  functional  schedules 
into  a  single  document.  It  requires  a  change  in 
scheduling.  Within  an  overall  schedule  tied  to  a 
capability  need  date  or  similar  milestone,  sched¬ 
ules  are  event-oriented  using  exit  criteria  tied  to 
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successful  completion  of  development  tasks  and 
incremental  product  releases.  The  SEMS  con¬ 
tained  in  the  annexes  to  the  development  speci¬ 
fications  are  key  building  blocks  of  the  System/ 
Subsystem  Integrated  Master  Schedule. 

Contractor  integrated  product  development 
teams  given  responsibility  for  Development 
Specifications,  Build-To  Packages,  Training 
Packages  and  Operation,  Support  and  Mainte¬ 
nance  Packages  are  responsible  for  developing 
and  maintaining  an  integrated  schedule  which  is 
“owned”  by  all  members  of  the  team.  Schedule 
milestones  are  negotiated  within  the  team  and 
are  the  basis  for  performance- based  progress 
criteria  and  risk  management.  All  disciplines 
must  assume  responsibility  for  meeting  the  inte¬ 
grated  schedule  and  event  milestones.  The  focus 
of  all  members  of  the  team  is  on  the  timely  com¬ 
pletion  of  the  specification  verification  tasks  and 
the  timely  release  of  a  quality  Build-To-Pack- 
age,  Training  Package  and  Operation,  Support 
and  Maintenance  Package.  Schedules  are  cre¬ 
ated  from  a  detailed  understanding  of  the  speci¬ 
fication  verification  tasks,  Build-To-Package 
content ,  Training  Package  content  and  Opera¬ 
tion,  Support  and  Maintenance  Package  content 
together  with  the  capability  and  capacity  of  the 
resources  required.  Caution  should  be  exercised 
in  using  historical  engineering  development 
times,  manufacturing  span  times,  training  sys¬ 
tem  development  times  and  support  develop¬ 
ment  times  in  building  the  schedules. 

3.6  Funding  Profile  Impacts  on  the  Inte¬ 
grated  Product  Development  Process 

Money  phasing  is  a  critical  element  of  inte¬ 
grated  product  development.  Improper  funding 
introduces  major  risks  because  it  impacts  the 
ability  to  keep  the  program  in  technical  balance. 
Scheduling  of  technical  tasks  and  commitments 
to  their  accomplishment  by  key  technical  mile¬ 
stones  should  be  the  basis  for  determining  the 


funding  profile.  Significant  program  dollars 
could  be  saved  with  a  funding  profile  compat¬ 
ible  with  a  sound  technical  strategy  that  supports 
the  objective  of  integrated  product  develop¬ 
ment.  Funding  must  be  made  available  for 
inclusion  of  all  necessary  disciplines  early  in  the 
design  process.  This  will  change  the  traditional 
funding  profile  by  greater  up-front  loading  of 
costs.  Experience  shows  that  potential  savings 
in  development  and  life  cycle  costs  more  than 
offset  the  higher  initial  costs.  The  use  of  inte¬ 
grated  specifications  and  the  SIMS  is  intended 
to  provide  a  sound  basis  for  developing  the 
funding  profile. 


4.0  INTEGRATED  PRODUCT  & 
PROCESS  DEVELOPMENT 

4.1  Integrated  Product  Development 

Integrated  product  development  will  be  ac¬ 
complished  by  integrated  product  teams  respon¬ 
sible  for  accomplishing  all  activities  necessary 
to  develop  and  qualify  a  complete  Build-To- 
Package,  a  complete  Training  Package  and  a 
complete  Operation  Support  and  Maintenance 
Package.  This  activity  should  address  as  a  mini¬ 
mum  all  the  classical  development  activities 
including  manufacturing  engineering  and  plan¬ 
ning  and  logistics  engineering  and  planning. 

Each  integrated  product  team  should  function 
within  the  boundaries  established  by  the  prod¬ 
ucts  of  system  requirements  and  configuration 
definition  activity. 


Integrated  product  development  requires  that 
the  engineering  description  of  a  part,  assembly, 
etc.,  and  the  processes  to  build  and  support  the 
product  are  defined  simultaneously.  This  inte¬ 
grated  product  development  is  based  on  incre¬ 
mental  product  releases  which  ensure  that  all  re¬ 
quirements  are  compatible  by  horizontal  inte¬ 
gration  of  all  elements.  Figure  4  shows  an 
integrated  product  development  process  flow 
with  incremental  release  products  and  enhanced 
configuration  management. 

The  development  of  layouts  defining  the 
product  and  the  processes  to  produce  and  sup¬ 
port  it  are  fundamental  to  integrated  product 
development.  Layout  development  is  important 
to  avoid  redesign,  poorquality,  difficult  to  manu¬ 
facture  and  support  designs,  and  rework.  The 
layout  development  process  has  two  phases. 
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The  first  phase  of  layout  development  is 
defining  the  design,  manufacturing,  tooling,  and 
support  concepts.  Support  concepts  include 
conceptual  technical  orders  based  on  initial 
identification  of  support  equipment,  skills,  etc. 
Completion  and  release  of  conceptual  layouts 
provide  the  basis  for  make/buy  decisions,  gener¬ 
ating  interface  control  documents,  and  achiev¬ 
ing  a  multi-disciplinary  consensus  on  the  con¬ 
ceptual  system  configuration  and  operating  and 
support  concepts.  In  the  traditional  process, 
conceptual  layouts  may  be  created  but  are  not 
formally  documented  and  controlled. 

The  second  phase  of  layout  development  is 
the  creation  of  assembly  layouts.  These  layouts 
define  structural  joints,  manufacturing  splices, 
tooling  requirements  and  interfaces,  and  have 
structural  sizing  sufficient  to  proceed  with  de¬ 
tailed  design.  The  structural  and  systems  inter¬ 
faces  and  manufacturability,  assembly  and  sup- 
portability  elements  of  the  design  can  be  vali¬ 
dated  using  computer  graphics.  Assembly  lay¬ 
outs  are  also  formally  released  and  subject  to 
configuration  control.  The  creation  and  release 
of  assembly  layouts  is  one  of  the  major  differ¬ 
ences  between  integrated  product  development 
and  traditional  design  practices.  Assembly  lay¬ 
outs  facilitate  the  use  of  automated  design,  de¬ 
sign  analysis,  and  computer  integrated  manu¬ 
facturing  and  computer  aided  logistics  tools. 

In  the  next  phase  of  integrated  product  devel¬ 
opment,  detailed  part  and  assembly  Build-To- 
Packages  are  then  released.  These  Build-To- 
Packages  will  contain  all  the  information  neces¬ 
sary  for  a  manufacturer  to  build  the  required 
product.  This  requires  close  communications 
between  the  developer  of  the  product  and  its 
manufacturer.  Verification,  whether  it  be  per¬ 
formance,  fit,  function,  tool  proofing,  numerical 
control  definition,  etc.,  is  an  important  ingredi¬ 
ent  of  the  package  and  will  be  subject  to  configu¬ 
ration  control. 


The  three-dimensional/two-dimensional  (3D/ 
2D)  as  designed/as  planned  data  contains  a 
complete  geometric  description  and  if  available, 
a  feature  description,  of  the  product.  The  exact 
form  of  the  3D/2D  description  is  flexible  and 
can,  over  time,  adapt  to  anticipated  changes  in 
computer  graphics  technology  including  solids 
and  feature  based  modeling.  Traditionally,  as- 
designed  data  was  created  by  engineers  and  as- 
planned  data  was  created  by  production  plan¬ 
ners.  Under  integrated  product  development, 
both  must  work  together  to  create  the  complete 
product  description. 

The  Total  Bill  of  Material  will  provide  the 
manufacturer  with  a  single,  internally  consistent 
source  of  needed  data.  It  combines  the  engineer¬ 
ing  bill  of  material  and  the  manufacturing  bill  of 
material.  As-built  and  as-supported  information 
can  be  combined  with  the  as-designed  and  as- 
planned  data  into  a  total  bill-of-material  for  each 
part/assembly. 

Strength  data  captures  the  design  loads  infor¬ 
mation,  documents  the  critical  features  of  the 
product,  and  captures  all  the  design  margins. 
Weight  datais  included  for  tracking  actual  weight 
performance  by  the  manufacturing  shop.  The 
exact  form  of  the  data  should  be  flexible  and 
determined  to  a  large  extent  by  the  program.  The 
key  is  to  achieve  greater  discipline  in  the  process 
by  bringing  the  loads  and  strength  data  under 
configuration  management  rules  and  creating  a 
common  data  base  for  product  developers  and 
follow-on  repair  and  engineering  change  activi¬ 
ties. 

Tool  and  test  equipment  definition  data  is 
essentially  a  Build-To-Package  for  the  tools  and 
test  equipment  required  to  build  the  detailed  part 
or  assembly  covered  by  the  overall  Build-To- 
Package.  It  includes  3D/2D  data,  tool  order,  and 
tool  and  test  equipment  usage  information. 
Information  required  to  initiate  long  lead  tool 
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design,  fabrication,  and  procurement  efforts  (e.g., 
loft  surfaces,  tool  datum  planes,  forging  specifi¬ 
cations)  will  be  incrementally  released.  Sched¬ 
uling  of  these  incremental  releases  will  be  con¬ 
tained  in  the  integrated  plans  and  schedules. 

Numerical  Control  Data  provides  a  good 
description  of  a  product  from  a  manufacturers 
point  of  view.  This  data  is  provided  for  machin¬ 
ing  parts,  routing  sheet  metal  parts,  cutting 
composite  plies  and  for  tooling.  Traditionally, 
Numerical  Control  programming  has  been  done 
by  the  manufacturing  organization  based  on  data 
provided  by  Design  and  Planning.  Under  the 
integrated  product  development  process,  this 
activity  will  be  accomplished  as  an  integral  part 
of  the  Build-To- Package  and  tailored  to  the 
needs  of  the  manufacturer  whether  it  be  in-house 
or  subcontracted. 

Specification  requirements  contain  the  prod¬ 
uct  specifications  (hardware  and  software),  the 
verification/test  procedures  and  verification 
results  from  the  systems  engineering  process. 
For  example,  specifications  and  test  instructions 
are  included  to  validate  proper  operation  of  hy¬ 
draulics,  fuel,  and  electrical  subsystems  as  as¬ 
sembled  in  a  major  component.  For  individual 
pieces  of  equipment,  the  specification  require¬ 
ments  would  typically  include  the  procurement 
specification  and  all  qualification  test  require¬ 
ments. 

Manufacturing,  fabrication  and  assembly 
instructions  will  contain  all  the  information 
required  to  build  the  part  or  assembly.  It  will 
contain  any  necessary  visual  aids,  a  complete 
work  order  and  non-conformance  disposition 
rules  and  data.  Process  instructions  will  contain 
all  the  information  contained  in  process  specifi¬ 
cation  such  as  finish  requirements,  marking, 
labeling, packaging,  handling,  storage,  and  ship¬ 
ping  requirements;  Non-Destructive  Inspection 
requirements;  heat  treatment,  etc.,  which  apply 
to  the  part  or  assembly  These  instructions  should 


stand  alone  and  the  manufacturer  should  not 
refer  to  any  information  beyond  the  Build-To- 
Package.  The  packaging,  handling,  storage,  and 
transportation  (PHS&T)  requirements  shall  be 
developed  concurrently  with  PHS&T  require¬ 
ments  for  follow-on  support  to  insure  compati¬ 
bility.  The  work  order  will  contain  the  stock  re¬ 
quirements,  operations  sequence  planning,  tool 
requirements,  industrial  engineering  targets,  etc. 
Manufacturing,  fabrication  and  assembly  in¬ 
structions  have  traditionally  been  generated  after 
the  product  definition  was  released.  Under  inte¬ 
grated  product  development  they  are  included  in 
the  Build-To-Package  and  early  estimates  of  this 
information  are  used  to  generate  the  schedule  for 
Build-To-Package  release. 

V erification  Requirements  provide  the  means 
for  clearly  communicating  the  important  factors 
for  fabrication  of  the  part/assembly  from  the  in¬ 
tegrated  product  team  to  the  manufacturer.  Any 
special  fit,  form,  function,  information  devel¬ 
oped  will  be  included. 

The  Operations,  Support  and  Maintenance 
Package  should  be  developed  in  parallel  with  the 
Build-To-Package  to  capitalize  on  synergistic 
effects.  Substantial  benefits  should  be  achieved 
in  the  areas  of  spares  definition,  diagnostics, 
support  and  test  equipment,  technical  data,  train¬ 
ing,  software  support,  etc.  To  the  extent  practi¬ 
cal,  the  support  data  will  utilize  the  data  from  in¬ 
tegrated  development  in  the  form  of  Build-To- 
Packages  to  develop  the  Logistics  Support 
Analysis  Record  and  the  provisions  for  life 
management  as  was  qualified  with  the  product. 
Definition  data  for  products  of  the  Operations, 
Support  and  Maintenance  Package  are  essen¬ 
tially  Build-To-Packages  for  these  elements. 

The  integrated  product  development  process 
shall  accomplish  all  the  planning  necessary  for 
Manufacturing  Operations  and  Product  Support 
to  accomplish  the  Product  Deployment  and 
Support  functions. 
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4.2  Integrated  Product  Design  Tasks 

Agreements  must  be  reached  within  each  IPT 
on  the  design  tasks  and  their  completion  criteria. 
Criteria  used  for  implementing  the  product  de¬ 
sign  tasks  within  IPD  is  as  follows: 

Service  life  in  years;  design  usage  in  terms  of 
aircraft/platforms,  mission  profiles,  mission  mix; 
total  operating  hours  in  the  air/on  the  ground; 
and  the  number/type  of  operating  cycles  for  in¬ 
flight  operations,  ground  operations,  off  vehicle 
(intermediate  and  depot  shops)  will  be  docu¬ 
mented.  This  information  will  be  established 
through  close  coordination  between  the  pro¬ 
gram  offices,  the  user(s),  and  the  contractor.  It 
will  then  be  used  by  the  contractor  to  establish 
the  design  criteria  to  be  included  in  the  integrity 
program  documentation  that  will  be  used  to 
verify  compliance  with  requirements. 

Environmental  requirements  (operational, 
storage,  transportation,  etc.)  will  be  established 
and  used  to  verify  functional  performance 
throughout  the  environmental  range. 

Competitive  benchmarking,  logistics  support 
analysis  use  studies  and  comparative  analyses, 
technological  opportunities,  and  customer  needs 
will  be  used  to  establish  and  prioritize  major 
product  design  requirements,  constraints  and 
improvement  objectives.  The  best  products  in 
the  field  are  analyzed  in  detail  to  assure  that  the 
design  will  be  superior  in  all  aspects. 

Characteristics  of  material  to  be  used  in  the 
design  will  be  defiriedand  wo£n  case  matertlfr:  v 
characteristics  that  Will  tie  allowdl  tdpassthrodfh 
the  manufacturing  and/or  maintenance  proc¬ 
esses  and/or  process  control/inspection  proc¬ 
esses  will  be  identified.  Prbcetsrtipfbnhiettt^l, 
process  control  ro^juif'ftthents  will  be  established 
using  process  capability  studies,  process  model¬ 
ing/analysis,  parameter  design  and  tolerance 
design  techniques,  as  appropriate. 


Design  criteria  and  design  margins  will  be 
established  that  are  sufficient  to  achieve  an  ac¬ 
ceptable  design  service  life  and  stable  manufac¬ 
turing  processes,  compatible  with  the  design 
requirements  to  minimize  scrap  and  rework. 
Design  criteria  will  also  be  established  for  as¬ 
sembly,  testability  and  for  maintainability  to 
include  manpower,  skill  levels,  repair  times  and 
repair  tools/equipment. 

Manufacturing  feasibility,  design  for  assem¬ 
bly,  design  for  maintainability,  and  design  to 
cost  analyses  will  identify  the  most  economical 
means  of  production  through  individual  or  col¬ 
lective  consideration  of  design  criteria,  materi¬ 
als  selection,  manufacturing  techniques  or  proc¬ 
esses,  and  repair  techniques  or  processes.  New 
manufacturing  and  repair  technology  require¬ 
ments  will  be  identified. 

Components  that  meet  the  required  service 
life  will  be  identified  and  life  limited  items/com¬ 
ponents  will  be  identified  with  their  life  limits. 

Preliminary  analysis  of  the  design  will  be 
complete  prior  to  Conceptual  Layout  Release 
and  formal  analyses  will  be  performed  prior  to 
Assembly  Layout  Release  on  components  of  the 
system  to  evaluate  their  initial  and  residual 
strength,  life  requirements,  and  maintainability 
requirements. 

Testing  of  materials,  parts,  and  components 
will  be  performed  to  the  design  usage  spectrum 
to  simulate  usage  environment,  to  verify  life 
analysis  procedures,  to  verify  allowable  stress 
and  strain  levels,  materials  selection,  etc.,  and  to 
develop  guidance  for  truncating  durability  tests. 

Damage  tolerance  and  durability  control 
finding  will  identify  and  define  all  of  the  tasks 
necessary  to  ensure  compliance  with  damage 
tolerance  and  durability  requirements.  This  will 
include  corrosion  prevention  and  control,  envi¬ 
ronmental  protection,  materials  selection  and 


materials  procurement  specification  require¬ 
ments,  manufacturing  process  specification 
requirements,  critical  design  drawing  informa¬ 
tion,  and  incremental  verification  of  subsystem 
and  equipment  maintainability  requirements. 

One  lifetime  of  durability  testing  will  be 
completed  prior  to  the  Build-To-Package  Re¬ 
lease.  This  will  be  supported  by  ground  test  and 
flight  survey  data,  as  appropriate.  Two  lifetimes 
of  durability  testing  plus  a  close  visual  inspec¬ 
tion  will  be  completed  prior  to  the  full  rate 
production  decision.  If  the  economic  life  is 
reached  prior  to  two  lifetimes,  testing  will  end 
and  an  analysis  will  be  required  to  determine  if 
production  changes  are  required.  Durability 
testing  including  development  testing  and  quali¬ 
fication  testing  will  be  performed  on  develop¬ 
ment  units  that  are  representative  of  the  produc¬ 
tion  configuration.  It  will  be  performed  on  the 
full  subsystem  or  on  major  assemblies  as  ap¬ 
proved  by  the  program  office.  All  inspection/ 
diagnostic  procedures  and  intervals  used  on  the 
durability  test  article(s)  will  be  the  same  as  those 
scheduled  for  operational  use. 

Damage  tolerance  testing  will  demonstrate 
compliance  with  the  damage  tolerance  design 
requirements  for  one  design  service  life  or  the 
maintenance/failure-free  operating  period  prior 
to  the  Build-To-Package  Release.  Damage  tol¬ 
erance  testing  will  be  flexible  and  tailored  to 
specific  systems.  The  size  of  the  test  program 
will  depend  on  the  number  of  assemblies  in  the 
test,  extent  of  verification  obtained  during  dura¬ 
bility  testing,  and  the  extent  of  previous  compo¬ 
nent  tests.  Detailed  test  requirements  (type  of 
tests,  quantity,  choice  of  specimens,  damage/ 
fault  locations,  etc.)  will  be  established  by  the 
contractor  and  approved  by  the  program  office. 
Corrective  actions  (e.g.,  design  changes,  special 
inspections  or  process  changes)  will  be  required 
for  deficiencies  disclosed  during  these  tests. 

Durability/damage  tolerance  test  results  along 


with  a  hardware  quality  audit  and  failure  analy- 
ses/fractographic  examinations  will  be  used  to 
demonstrate  that  requirements  are  met  or  the 
impacts  resulting  from  deficiencies  are  quanti¬ 
fied  to  support  program  decisions.  A  hardware 
quality  audit  and  failure  analyses/fractographic 
examination  will  be  performed  upon  completion 
of  the  durability/  damage  tolerance  testing  for 
the  purpose  of  locating  critical  areas  not  previ¬ 
ously  identified;  verifying  life  (age)  limits;  as¬ 
sessing  the  adequacy  of  inspection/diagnostic 
procedures  and  intervals;  and  assessing  the  ini¬ 
tial  quality  of  the  equipment.  The  scope  of  the 
inspection,  the  specific  inspection  procedures 
used,  and  the  extent  of  the  detailed  examinations 
will  be  tailored  for  each  program. 

Manufacturing  processes  will  be  proofed 
before  the  Build-to-Package  Release  and  vali¬ 
dated  during  Low  Rate  Initial  Production  (LRIP) 
to  confirm  the  adequacy  of  the  production  plan¬ 
ning,  tool  design,  assembly  procedures,  work 
instructions,  training  procedures,  etc.  Manufac¬ 
turing  process  proofing  and  validation  will  be 
done  at  the  prime  contractors,  subcontractors, 
and  key  suppliers.  Rapid  prototyping  and  com¬ 
puter-aided  visualization  techniques  such  as 
animation,  simulation,  and  rendering  systems 
may  be  used  to  support  the  proofing  process. 

Failure  investigations/analyses  will  be  per¬ 
formed  during  design,  development,  qualifica¬ 
tion,  and  production  to  ensure  timely  identifica¬ 
tion  of  root  causes  and  corrective  actions,  and  an 
assessment  of  the  effectiveness  of  the  imple¬ 
mented  corrective  actions. 

Verification  compliance  planning  will  be 
completed  and  verified  prior  to  Build-To-Pack- 
age  Release,  validated  during  LRIP,  and  fully 
implemented  during  full  rate  production.  This 
planning  will  include  manufacturing  process 
controls  and/or  inspection  requirements  derived 
from  the  design  criteria.  Process  control  re¬ 
quirements  will  be  established  for  each  level  of 


assembly  (statistical  process  controls,  adaptive 
machine  controls,  environmental  stress  screen¬ 
ing,  non-destructive  procedures,  automated  in¬ 
spections,  etc.)  based  on  material  characteriza¬ 
tion,  manufacturing  process  variability  and 
strength/durability  requirements.  The  planning 
information  will  also  cover  the  failure  reporting/ 
feedback  process  including  physics  of  failure 
analysis  and  disposition  criteria  for  non-con- 
forming  material  based  on  the  failures  affect  on 
functional  performance  and  life.  Material  man¬ 
agement  of  critical,  controlled  or  strategic  mate¬ 
rial  will  be  included. 

Subsystem  and  equipment  level  maintaina¬ 
bility  analyses  will  be  completed  prior  to  Build- 
To-Package  Release.  Incremental  maintainabil¬ 
ity  verifications  will  be  completed  on  develop¬ 
mental  items  from  components  to  configuration 
items  and  formal  maintainability  demonstra¬ 
tions  will  be  completed  prior  to  the  LRIP  go- 
ahead  decision.  Maintainability  demonstrations 
will  be  conducted  in  an  environment  which 
simulates,  as  closely  as  practicable,  the  opera¬ 
tional  and  maintenance  environment  planned 
for  the  item.  This  environment  will  be  represen¬ 
tative  of  the  installation  conditions,  working 
conditions,  tools,  support  equipment,  spares, 
facilities,  and  technical  publications  that  would 
be  required  during  operational  service  at  the 
defined  maintenance  level  and  will  be  accom¬ 
plished  by  personnel  of  the  equivalent  skill  level 
having  received  the  specified  training. 

Provisions  for  life  management  will  be  com¬ 
pleted  prior  to  the  LRIP  go-ahead  decision, 
verified  prior  to  completion  of  Initial  Opera¬ 
tional  Test  and  Evaluation  (IOT&E),  and  imple¬ 
mented  on  all  fielded  equipment.  Life  manage¬ 
ment  provisions  will  include  the  expected  break 
rates  for  the  equipment,  the  time  phased  mainte¬ 
nance  tasks  for  preventive/schedule  maintenance, 
mai  ntenance  process  control  s/i  nspection  requ  ire- 
ments,  the  expected  fix  rates  for  the  equipment, 
the  process  and  devices  for  monitoring  field 


usage  and  installed  environments,  a  metho  '1- 
ogy  for  modifying  break  rate  prediction  and 
maintenance  tasks  based  on  changes  in  opera¬ 
tional  usage  and  installed  environments,  and 
provisions  for  updating  the  Logistics  Support 
Analysis  Record.  Life  management  data  will 
provide  a  continual  assessment  of  the  in-service 
integrity  of  the  equipment;  provide  a  basis  for 
determining  logistics  and  force  planning  re¬ 
quirements;  and  provide  a  basis  to  improve 
design  criteria  and  methods  of  design,  evalu¬ 
ation,  and  substantiation  for  future  systems/ 
equipments. 

This  integrated  design  process  is  responsive 
to  the  objectives  of  integrated  product  and  proc¬ 
ess  development.  Many  of  the  elements  of  this 
process  are  already  established  in  the  product  in¬ 
tegrity  programs.8 

4.3  Integrated  Technical  Reviews 

Technical  reviews  are  an  integral  and  essen¬ 
tial  part  of  IPD.  Technical  reviews  can  range 
from  very  formal  reviews  to  very  informal  re¬ 
views  concerned  with  product  and/or  verifica¬ 
tion  elements  of  the  development  specification. 
All  reviews  share  the  objective  of  determining 
the  technical  adequacy  of  the  existing  product 
and  process  design  to  meet  requirements. 

As  the  acquisition  program  moves  through 
the  life  cycle,  the  reviews  become  more  detailed 
and  definitive.  Technical  reviews  consider  all 
aspects  of  the  product  and  process  design  that 
are  relevant  to  the  progress  of  a  particular  design 
phase.  Contracts  will  require  formal  technical 
reviews  that  will  be  structured  to  fulfill  the  two 
main  purposes  of  the  technical  review,  which 
are:  (1)  to  augment  with  additional  knowledge 
the  integrated  product  design  and  analytical  ac¬ 
tivity;  and  (2)  to  evaluate  accomplishment  of 
specified  design  and  verification  tasks  which 
need  approval  before  proceeding  to  the  next  step 


in  the  acquisition  process. 

Technical  reviews  are  used  as  the  process 
control  mechanism  for  a  program.  As  such,  the 
specifications  form  the  cornerstone.  The  speci¬ 
fications  are  bi-lateral  agreements  between  in¬ 
dustry  and  the  government  on  the  requirements 
and  the  process  for  achieving  these  requirements 
as  documented  in  the  Systems  Engineering 
Master  Schedule  (SEMS).  Other  contractual 
requirements  are  captured  in  the  Statement  of 
Work.  The  process  for  meeting  these  require¬ 
ments  are  combined  with  the  SEMS  to  make  the 
System/Subsystem  Integrated  Master  Schedules 
(SIMS).  Technical  Performance  Measurements 
are  used  to  establish  the  entry  and  exit  criteria  for 
each  requirement  while  the  event-oriented 
SEMS/SIMS  provide  the  verifiable  success  cri¬ 
teria  and  entry  and  exit  criteria  for  the  process  of 
meeting  the  requirement.  Using  these  tools 


readiness  for  formal  reviews  are  incrementally 
assessed  using  the  status  as  entry  criteria  with 
the  formal  review  being  the  final  confirmation 
of  readiness  to  proceed.  This  process  is  used  to 
create  the  agendas  for  the  reviews  which  ulti¬ 
mately  culminates  in  a  series  of  approved  prod¬ 
ucts.  Several  key  products  are  the  system  speci¬ 
fication,  development  specifications,  interface 
control  documents,  conceptual  layouts,  assem¬ 
bly  layouts,  build-to-packages,  training  pack¬ 
ages  and  operation,  support  and  maintenance 
packages.  Successfully  incremental  completion 
of  this  process  is  tied  to  contract  demonstration 
milestones  and  to  progress  payments. 

Figure  5  shows  a  matrix  of  requirements  and 
accomplishments  tied  to  program  milestones 
and  system/subsystem  incremental  reviews.  This 
correlation  matrix  can  be  used  to  help  in  plan¬ 
ning  for  the  reviews. 
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Technical  reviews  and  audits  focus  on  the 
total  product  including  its  manufacturing,  sup¬ 
port  and  training.  As  such,  software,  logistics, 
test  and  production  process  reviews  are  an  inte¬ 
gral  part  of  each  su  stem’s  incremental  re¬ 
view.  Figure  6  shows  a  series  of  formal  reviews 
that  reflect  an  integrated  approach  within  an  IPD 
framework.  This  approach  reflects  early  baselin¬ 
ing  of  performance  requirements  and  configura¬ 
tion  definition  data  while  deferring  government 


configuration  control  of  the  detailed  build-to 
information.  Technical  reviews  and  audits  cul¬ 
minate  with  the  validation  of  the  Build-To- 
Packages  and  the  Operation,  Support  and  Main¬ 
tenance  Package  (including  the  Training  Pack¬ 
age)  with  the  as-built/produced  products  and 
DT&E/IOT&E  and  Factory  Tests.  Incremental 
approval  of  the  key  products  establish  the  baseline 
for  configuration  management. 
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5.0  CONFIGURATION  MANAGEMENT 

Configuration  Management  supports  the  sys¬ 
tems  engineering  management  process  and 
ensures  the  integrity  and  continuity  of  the  prod¬ 
uct  and  process  designs  throughout  their  life 
cycle.  This  process  involves  the  functions  of 
identification,  interface  control,  configuration 
control,  audits  and  status  accounting  as  shown  in 
figure  6.  Baseline  management  is  one  of  the 
more  important  elements  of  this  process.  These 
baselines  should  be  the  product  of  the  integrated 
technical  reviews  and  audits.  Under  integrated 
product  development,  layouts  are  used  to  en¬ 
hance  product  definition.  For  example,  the  use 
of  automated  design  tools  has  made  the  assem¬ 
bly  layout  the  cornerstone  of  the  detailed  design, 
design  analysis,  computer  integrated  manufac¬ 
turing  and  computer  aided  support.  As  such,  the 
conceptual  layouts  and  the  assembly  layouts 
will  be  subject  to  configuration  management 
rules.  A  description  of  the  layout  process  is 
contained  in  the  section  on  Integrated  Product 
Development.  This  section  also  describes  the 
Build-To-Package  and  Operations,  Maintenance 
and  Support  Package  contents  which  will  also  be 
subject  to  configuration  management  rules. 
These  packages  contain  all  the  information 
necessary  to  build,  operate  and  support  the  prod¬ 
uct.  These  packages  often  contain  electronic 
products  and  go  well  beyond  the  traditional 
DOD-STD- 100  drawings. 

Integrated  product  development  requires 
control  of  product  and  process  configuration  at 
all  levels,  not  just  for  drawings  as  it  is  done 
today.  Increased  interactions  of  many  disci¬ 
plines  with  the  product  definition  and  product 
and  process  development  activities  and  the  use 
of  common  data  bases  contributes  to  this  need. 
Product  data  must  be  managed  to  ensure  all 
personnel  are  working  with  the  latest  applicable 
data.  This  includes  the  means  for  change  notifi¬ 
cation  to  inform  users  of  data  when  revisions  are 
made.  Providing  common  access  to  product 


definition  data  brings  with  it  the  responsibility 
to  find  data  and  manage  that  data  including 
versioning  data  at  the  part  level  as  well  as  captur¬ 
ing  specific  part  or  subcomponent  attributes. 
For  these  reasons,  contractors  must  have  a  dif¬ 
ferent  kind  of  configuration  management  sys¬ 
tem  than  they  had  in  the  past. 

Integrated  product  development  requires  early 
baselining  of  the  system  and  development  speci¬ 
fications  and  interface  controls  with  supporting 
layouts  while  deferring  government  approval  of 
Build-To-Packages  and  Operations,  Mainte¬ 
nance  and  Support  Packages  until  completion  of 
the  final  audit  of  these  documents.  The  govern¬ 
ment  is  responsible  for  the  requirements  while 
the  contractor  is  responsible  for  generating  the 
data  to  assist  in  the  trade-offs  needed  to  reach  a 
balanced,  affordable  set  of  requirements.  The 
contractor  is  responsible  for  the  design  with 
government  assistance  u.  nelping  to  select 
alternative  designs  that  meet  the  requirements. 
This  provides  for  both  government  and  contrac¬ 
tor  clear  accountability  in  design.  It  provides  for 
up-front  mutual  agreement  on  the  requirements 
stated  in  performance  terms  at  the  system  and 
major  subsystem  level  and  the  tasks,  accom¬ 
plishments  and  success  criteria  for  achieving 
them.  Only  after  successful  completion  of  these 
agreements  will  the  Build-To-Packages  and 
Operations,  Maintenance  and  Support  Packages 
be  subject  to  government  control  thus  eliminat¬ 
ing  premature  approval  of  product  specifica¬ 
tions  as  may  be  the  case  under  the  current  proc¬ 
ess. 

These  are  just  a  few  of  the  features  required  of 
the  contractor’s  configuration  management 
system  in  the  IPD  environment. 
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6.0  INFORMATION  TECHNOLOGIES 
6.1  Information  Integration  Technologies 

The  concept  of  integrated  product  develop- 
«  ment  deals  with  the  interaction  among  different 

weapon  system  development  specialists  who  are 
responsible  for  their  own  specific  functional 
f  area,  but  who  also  work  together  as  a  team  to 
make  the  trade  offs  which  contribute  to  the  best 
possible  product.  Given  the  complexity  of  the 
end  product,  the  vast  number  of  decisions  which 
must  be  made  and  the  large  organizations  re¬ 
sponsible  for  these  decisions,  computer  systems 
are  widely  used  to  support  the  development 
process.  In  the  last  three  or  four  years,  dramatic 
improvements  have  been  demonstrated  in  the 
application  of  computer  aided  design  (CAD), 
computer  aided  manufacturing  (CAM),  data¬ 
base  software  systems  and  workstation  technol¬ 
ogy  in  selected  engineering,  manufacturing  and 
support  areas.  These  technologies  have  excel¬ 
lent  potential  to  support  the  implementation  of 
the  integrated  product  development  approach  in 
Air  Force  weapon  systems  acquisition  and  the 
technology  development  for  weapon  systems. 
For  example,  new  modeling  techniques  based 
on  the  use  of  CAD  systems  with  increased  mathe¬ 
matical  completeness  and  accuracy  have  in¬ 
creased  the  ability  to  visualize  assemblies  at  the 
design  stage,  including  the  sequencing  of  com¬ 
ponents  during  assembly  and  the  potential  inter¬ 
ferences  of  mating  parts.  For  machined  parts, 
verification  of  machinability  can  be  determined 
by  the  animation/simulation  of  cutter  path  travel 
using  the  solid  modeling  capabilities  of  CAD 
•  systems.  Reliability  and  Maintainability  (R&M) 

Computer  Aided  Design  (RAMCAD)  applica¬ 
tion  packages  now  permit  a  more  rapid  analysis 
1  and  modification  of  the  design  to  better  support 

R&M.  These  kinds  of  techniques  increase  the 
ability  of  design,  manufacturing  and  support 
engineers  to  interact  on  an  analytical  basis  early 
in  the  design  phase.  Use  of  the  electronic  model 
can  highlight  the  needed  changes  before  com¬ 


mitments  are  finalized  and  thereby  reduce  or 
potentially  eliminate  the  amount  of  expensive 
change  required  to  the  physical  part  during 
development.  In  the  management  support  (text) 
area,  software  systems  have  become  more  user 
friendly  and  responsive  to  the  need  for  informa¬ 
tion  through  the  use  of  relational  data  bases  and 
other  advanced  data  base  techniques.  Increased 
computer  power  at  the  mainframe  level  and  the 
proliferation  of  relatively  low  cost,  yet  powerful 
workstations  have  greatly  increased  the  com¬ 
puter  power  available  to  the  average  aerospace 
engineer. 

The  significantly  improved  visualization  ca¬ 
pabilities  and  accuracies  from  specially  modi¬ 
fied  CAD  systems  have  resulted  in  more  reli¬ 
ance  on  electronic  development  fixtures  which 
take  the  place  of  physical  mock-ups.  Rapid 
prototyping  through  the  use  of  solid  modelers, 
rule  based  systems  and  other  design,  manufac¬ 
turing  and  support  techniques  such  as  stere¬ 
olithography  are  becoming  more  commonplace. 
Aerospace  companies  have  recognized  these 
technologies  as  significant  enablers  that  help  to 
implement  integrated  product  development  and 
thereby  increase  design,  manufacturing  and 
support  interaction  and  efficiency.  Early  in¬ 
volvement  and  review  of  this  capability  with  the 
program  office,  users  and  AFLC  could  signifi¬ 
cantly  enhance  early  dialogue  and  agreement  on 
design  rules  and  analysis  techniques.  Accurate 
three  dimensional  modeling  capabilities  (al¬ 
though  computationally  intense)  and  the  trans¬ 
mittal  of  electronic  CAD  files  across  different 
computer  systems  within  a  company  (and  across 
different  contractors)  have  demonstrated  the  ac¬ 
tual  construction  and  assembly  of  development 
components  with  a  minimum  of  interference  and 
rework.  Some  companies  are  realizing  a  part  fit 
of  over  80%  on  first  time  articles  without 
modification  and  actual  time  to  completion  is 
40%  less  than  estimated.  These  capabilities 
were  first  demonstrated  on  the  large  mainframe 
computers  found  within  aerospace.  Similar  ca- 
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pabilities  are  now  becoming  more  common¬ 
place  on  relatively  inexpensive  workstation 
systems  and,  given  the  competition  which  exists 
in  this  marketplace,  significantincreasesin  work¬ 
station  capability  are  expected  in  the  near  term. 
The  use  of  this  technology  has  great  potential  for 
cost  savings  if  effectively  used  across  the  board 
by  contractors  (prime  and  subs)  and  the  Air 
Force  in  the  development  of  weapon  systems. 
ASD,  in  their  program  management  and  techni¬ 
cal  oversight  role  should  consider  information 
integration  from  three  perspectives:  (1)  To  en¬ 
courage  and  allow  the  contractors  to  move  toward 
the  use  of  integrated  systems  and  thereby  be¬ 
come  more  efficient,  (2)  To  internally  use  se¬ 
lected  amounts  of  information  and  supporting 
computer  technology  in  an  integrated  way  to 
accomplish  the  program  management  and  tech¬ 
nical  oversight  role  and  to  interface  with  the 
contractor,  users  and  AFLC  in  a  more  efficient 
manner,  and  (3)  To  provide  AFLC  with  more  ap¬ 
propriate,  accurate  and  timely  information  for 
their  use. 


6.2  Opportunities/Challenges/Issues 

There  are  many  challenges  to  the  implemen¬ 
tation  of  an  integrated  information  management 
strategy  in  support  of  Integrated  Product  Devel¬ 
opment.  Examples  of  these  challenges  are: 

•  Data  Security.  These  issues  involve  Gov¬ 
ernment  access  to  proprietary  contractor  data, 
including  concerns  over  an  invasion  of  privacy 
and  the  potential  exposure  of  sensitive  informa¬ 
tion  to  competitors.  These  issues  can  also  in¬ 
volve  data  security  and  the  ability  to  keep 
“hackers”  from  gaining  access  to  the  informa¬ 
tion. 

•  Configuration  Management  in  weapon  sys¬ 
tem  development  can  take  an  innovative  ap¬ 
proach  based  on  the  management  of  an  elec¬ 
tronic  data  set  instead  of  engineering  drawings. 


Major  improvements  are  possible.  The  process 
definition  will  be  concurrently  evolved  at  the 
same  time  as  the  product  definition,  most  likely 
in  an  highly  iterative  manner.  Configuration 
management  techniques  must  also  be  applied  to 
the  data  base(s)  that  contain  the  product  and 
process  definition.  Cultural  changes  are  re¬ 
quired  to  make  these  changes. 

•  Technical  Data  Management  can  transi¬ 
tion  from  paper  intensive  processes  to  digital 
data  delivery  and  access.  There  is  a  need  for  a 
common  understanding  between  the  Air  Force, 
prime  contractors,  subcontractors  and  vendors 
on  what  information  is  required  to  carry  out  the 
integrated  development  process,  when  it  should 
be  delivered,  in  what  form  and  how  it  should  be 
formatted  and  transmitted.  This  includes  a  need 
for  a  better  understanding,  within  ASD  inte¬ 
grated  product  development  teams  of  what  in¬ 
formation  different  functional  members  (on 
multifunctional  teams)  need  to  do  their  job. 
There  is  a  need  to  develop  an  overall  information 
architecture  or  framework. 


6.3  Role  of  Computer-Aided  Acquisition 
and  Logistics  Support  (CALS) 

CALS  is  a  DOD  and  Industry  strategy  to 
enable,  and  to  accelerate,  the  integration  of  digi¬ 
tal  technical  information  for  weapon  system 
acquisition,  design,  manufacture,  and  support. 
CALS  is  intended  to  provide  for  an  effective 
transition  from  current  paper-intensive  weapon 
system  life  cycle  processes  to  the  efficient  use  of 
digital  information  technology.  The  objectives 
of  CALS  as  stated  in  MIL-HDBK-59,  "Depart¬ 
ment  of  Defense  Computer-Aided  Acquisition 
and  Logistics  Support  (CALS)  Program  Im¬ 
plementation  Guide,"  are: 

•  To  accelerate  the  integration  of  design  tools 
such  as  those  for  reliability  and  maintainability 
into  contractor  computer-aided  design  and  engi- 
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neering  systems  as  part  of  a  systematic  approach 
that  simultaneously  addresses  the  product  and 
its  life  cycle  manufacturing  and  support  require¬ 
ments. 

•  To  encourage  and  accelerate  the  automa¬ 
tion  and  integration  of  contractor  processes  for 
generating  weapon  system  technical  data  in 
digital  form. 

•  To  rapidly  increase  DOD’s  capabilities  to 
receive,  store,  distribute,  and  use  weapon  sys¬ 
tem  technical  data  in  digital  form  to  improve  life 
cycle  maintenance,  training,  and  spare  parts 
reprocurement,  and  other  support  processes. 

Currently,  a  variety  of  automated  systems  are 
utilized  by  weapon  system  contractors  working 
as  a  production  team  to  enter,  update,  manage, 
and  retrieve  data  from  data  bases  associated  with 
specific  acquisition  programs.  Many  of  these 
systems  are  incompatible  with  one  another  as 
well  as  with  similar  systems  employed  by  the 
government  to  receive,  store,  process,  and  use 
delivered  technical  data.  The  functional  capa¬ 
bilities  supported  by  these  diverse  systems  vary 
greatly.  Data  created  in  one  functional  process 
is  often  manually  re-entered  or  re-created  in 
subsequent  functional  processes,  thereby  intro¬ 
ducing  errors  and  increasing  costs. 

The  near  term  goals  for  CALS  implementation 
are  attainment  of  increased  levels  of  interfaced, 
or  integrated,  functional  capabilities,  and  speci¬ 
fication  of  requirements  for  limited  government 
access  to  contractor  technical  data  bases,  or  for 
delivery  of  technical  data  to  the  government  in 
digital  form. 

These  specifications  are  designed  to  comply 
with  widely  accepted  commercial  standards 
developed  for  these  purposes. 


mon  data  in  an  Integrated  Weapon  System  Data 
Base  (IWSDB)  structure  that  is  implemented 
through  Contractor  Integrated  Technical  Infor¬ 
mation  Service  (CITIS)  and  government  techni¬ 
cal  information  systems.  Data  deliverables  from, 
or  government  access  to,  specified  segments  of 
CITIS  data  should  be  required  in  future  con¬ 
tracts  and  developed  in  accordance  with  CALS 
standards  and  procedures. 

MIL-HDBK-59  provides  information  and 
guidance  to  personnel  responsible  for  the  acqui¬ 
sition  and  use  of  weapon  system  technical  data. 
Its  purpose  is  to  assist  in  the  transition  from 
paper-intensive  processes  to  digital  data  deliv¬ 
ery  and  access.  It  also  supports  the  structuring  of 
contract  requirements  to  achieve  integration  of 
various  contractor  automated  capabilities  for 
design,  manufacturing,  and  logistics  support. 


The  longer  term  goals  of  CALS  is  integration 
of  industry  and  DOD  data  bases  to  share  com- 
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7.0  INTEGRATED  PRODUCT  contractor  IPDTs  are  organized  to  achieve  the 

DEVELOPMENT  TEAMS  following  overall  responsibilities: 


A  key  feature  of  successful  implementation  of 
integrated  product  development  is  the  establish¬ 
ment  of  collocated,  multifunctional,  empow¬ 
ered,  integrated  product  development  teams 
(IPDTs).  Early  involvement  of  all  disciplines 
(design,  manufacturing,  configuration  manage¬ 
ment,  test,  logistics,  etc.)  working  as  a  team  to 
integrated  requirements  and  schedules  signifi¬ 
cantly  reduces  the  rework  in  design,  manufac¬ 
turing  planning,  tooling  and  product  support 
planning.  Most  important  is  that  equal  empha¬ 
sis  of  both  product  and  process  development  is 
enhanced  through  the  multidisciplined  team 
approach.  Key  issues  in  the  success  of  the  IPDT 
approach  are  organizational  structure,  human 
resource  development  and  cultural  changes. 

7.1  Organization 

Successful  examples  of  the  Integrated  Product 
Development  Process  in  industry  reflect  the  use 
of  IPDTs.  Extending  the  use  of  IPDTs  within  the 
System  Program  Offices  (SPOs)  would  enhance 
the  government/industry  success  through  better 
communications  and  increased  focus  on  the 
product  and  its  manufacturing  and  support  proc¬ 
esses  as  opposed  to  vertical  functional  require¬ 
ments.  In  addition,  the  use  of  IPDTs  within  the 
SPOs  would  facilitate  the  development  of  inte¬ 
grated  requirements,  integrated  specifications, 
integrated  design  processes,  integrated  planning 
and  scheduling  and  integrated  technical  reviews; 
all  of  which  are  keys  to  successful  implementa¬ 
tion  of  the  IPD  process  as  discussed  early. 

The  team  concept  is  to  have  well  trained  people, 
organized  effectively  and  empowered  to  do  their 
job,  working  with  disciplined  systems  and  proc¬ 
esses.  It  is  envisioned  that  the  formulation  of 
IPDTs  within  major  SPOs  would  be  formed 
around  the  specification  tree.  Government  and 


•  Government  IPDTs  should  be  organized  to 
develop  an  integrated  properly  allocated  set  of 
requirements  at  the  performance  level,  from  the 
weapon  system  specification  down  to  the  lowest 
indentured  specification  appropriate  for  the 
acquisition. 

•  Contractor  IPDTs  should  be  organized  to 
translate  the  performance  requirements  into  a 
definitive  set  of  design  requirements  and  design 
criteria  and  transform  those  into  qualified  hard¬ 
ware  and  software  products. 

•  The  government  and  contractor  IPDTs 
interact  to  assist  each  other  in  achieving  the 
weapon  system  requirements.  The  contractor 
IPDTs  will  evolve  design  criteria  and  design 
solutions  to  meet  the  requirements.  As  the 
design  evolves,  further  explanation  of  a 
requirement  or  modification  to  a  requirement 
may  be  prudent.  The  government  IPDT  will 
review  the  requirement  and  the  data  generated 
by  the  contractor  IPDT  on  the  alternatives  and 
perform  the  weapon  system  technical/cost/ 
schedule  trade-offs  to  ascertain  the  preferred  set 
of  requirements  to  be  chosen.  Once  selected,  the 
contractor  will  perform  the  design,  develop¬ 
ment,  test  and  qualification  to  the  approved 
specification  requirements. 

•  The  government  IPDTs  interact  with  the 
contractor  IPDTs  during  evolution  of  the  design 
to  assist  in  decisions  on  design  choices  that  are 
the  purview  of  the  empowered  teams.  Numer¬ 
ous  design  selections  are  required  during  the 
process  that  are  fully  compliant  with  the  top- 
level  performance  requirement,  but  may  very 
well  offer  a  range  of  acceptability  to  the  user, 
support  and  training  communities.  In  these 
cases,  the  government  IPDT  will  review  the 
alternatives  with  these  communities  to  seek 
consensus  and  implement  a  balanced  decision. 
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To  accomplish  these  responsibilities,  four 
types  of  teams  are  envisioned;  a  management 
team,  integrated  product  teams,  functional  teams 
and  special  teams. 

The  management  team  (figure  7)  consists  of 


the  program  manager  and  the  functional  direc¬ 
tors.  This  team  would  be  responsible  for  the 
weapon  system  specification  and  would  provide 
overall  policy,  guidance  and  review  of  inte¬ 
grated  product  teams,  functional  teams  and 
special  team  activities. 


MANAGEMENT  TEAM 

(Example:  System  Level  Spec./Government) 


) 


Figure  7 
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Integrated  Product  Teams  (IPTs)  would  be 
structured  around  the  major  subsystems  of  the 
specification  tree.  Figure  8  is  an  example  of  an 
integrated  product  team  for  a  Radar  Subsystem. 

IPTs  should  be  tailored  to  each  program.  Some 
of  the  considerations  for  team  formulation  are: 

•  Extent  of  development  and  prime  contrac¬ 
tor/subcontractor  relationships. 

•  Empowered  teams  should  be  organized 
around  the  product  and  focused  on  the  develop¬ 
ment  of  both  the  product  design  and  its  manufac¬ 
turing  and  support  processes. 

•  The  prime  contractor  should  be  organized 
utilizing  the  IPTs  or  be  encouraged  to  do  so. 


•  Team  leaders  would  normally  come  from 
within  the  multifunctional  team.  Team  leader¬ 
ship  may  rotate  based  on  the  phase  of  the  program. 
For  example,  during  requirements  definition 
activities,  the  team  leader  may  come  from  the 
projects  organization;  during  development  ac¬ 
tivities,  the  team  leader  may  be  the  project  engi¬ 
neer;  during  transition  to  production  activities, 
the  team  leader  may  come  from  manufacturing; 
during  deployment,  the  team  leader  may  come 
from  logistics.  However,  regardless  of  whom¬ 
ever  is  designated  the  overall  team  leader,  the 
team  will  have  natural  leaders  responsible  for 
working  elements  of  the  project.  For  example, 
the  natural  leader  to  work  a  design  issue  would 
be  the  project  engineer,  a  test  issue  the  test  engi¬ 
neer,  a  manufacturing  issue  the  manufacturing 
team  member,  a  contracts  issue  the  contracts 


INTEGRATED  PRODUCT  TEAM 
(Example:  Radar  Subsystem/Government/New  Development) 
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representative.  Team  oversite  would  normally 
be  through  the  management  team. 

•  Team  members  who  spend  all  their  time  on 
one  product  should  be  collocated  together  to  fa¬ 
cilitate  communications  and  crossfeed  of  infor¬ 
mation. 

•  Team  changes  should  be  minimized  and  the 
team  should  remain  active  through  production 
and  initial  deployment. 

•  All  extended  team  support  requirements 
should  be  identified  and  a  responsible  person 
assigned. 

•  Team  meetings  must  be  attended  by  all  team 
members  and  extended  team  members  if  their 
specialty  will  be  addressed  during  the  meeting. 

•  Team  responsibilities  and  authority  should 
include: 

—  Participate  with  “customers”  to  develop 
and  evaluate  requirements. 

—  Develop  and/or  approve  internal  team 
schedules. 

—  Review  and  approve  designs  and  proc¬ 
esses. 

—  Review  and/or  approve  design  verifica¬ 
tion  activities  and  test  plans. 

—  Develop  and  approve  acquisition  plans 
and  strategies. 

—  Member  of  teams  should  have  appropri¬ 
ate  authority  to  represent  his/her  functional  within 
the  team. 

— Act  as  primary  interface  with  industry  on 
assigned  products. 

Functional  teams  will  normally  be  established 
todevelopcohesive  strategies  to  guide  and  ensure 
consistent  and  standard  practices  across  the  inte¬ 
grated  product  teams.  They  would  normally  be 
led  by  the  functional  director  or  division  chief  to 
address  requirements  such  as  tooling,  facilities, 
or  maintenance  concepts  for  the  entire  weapon 


system.  The  SPO  functional  team  should  ensure 
a  properly  allocated  set  of  performance  oriented 
requirements  or  constraints  at  the  weapon  sys¬ 
tem  level.  They  will  also  resolve  any  issues  that 
impact  this  policy  or  these  requirements  brought 
to  them  for  resolution  by  the  responsible  inte¬ 
grated  product  teams.  Issues  may  occur  as  a 
result  of  impacts  on  facilities,  test  equipment, 
support  equipment  or  the  product  design  that 
may  require  trade-offs  and  compromises. 
Through  their  interfaces  with  the  integrated 
product  teams  the  functional  team  will  be  re¬ 
sponsible  for  ensuring  a  consistent  flow  of  re¬ 
quirements  to  the  lowest  indentured  specifica¬ 
tion  appropriate  for  the  acquisition,  resolve  any 
issues  in  implementation  that  may  occur  during 
development,  and  ensure  acceptability  of  the 
decision  to  the  users  that  may  be  impacted. 
Figure  9  is  an  example  of  a  tooling  team  which 
would  logically  be  led  by  a  manufacturing  or¬ 
ganization. 

Other  special  SPO  teams  may  also  be  estab¬ 
lished  as  program  office  needs  dictate.  An 
example  of  a  special  team  is  shown  in  Figure  10. 
This  example  represents  a  team  working  the 
requirements  definition  for  an  extensive  avion¬ 
ics  and  structural  modification  to  an  aircraft 
design. 
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SPECIAL  FUNCTIONAL  TEAM 
(Example:  Block  XY  Requirements  Definition) 
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Functional  teams  also  serve  a  useful  function 
at  the  ASD  "corporate"  home  office  level.  For 
example,  to  facilitate  an  on-going  linkage  of 
design  and  manufacturing  engineering  efforts, 
standing  technical  teams  dealing  with  produci- 
bility  and  process  control  issues  may  be  needed 
in  specialized  functional  areas  such  as: 

•  Composites 

•  Electronics  and  Microelectronics 

•  Materials,  Components  and  Processes 

•  Metallurgy  and  Chemical  Treatments 

•  Automation,  CAD,  CAM,  Computer- 

Integrated  Manufacturing 

These  teams  would  consist  of  appropriate  design 
engineers,  manufacturing  engineers,  quality 
engineers  and  laboratory  representatives.  The 
purpose  of  such  teams  would  be  to  integrate 
design  guidance-includingdesign  requirements 
and  design  criteria  to  be  imposed  through  the 
product  integrity  program  specifications,  stan¬ 
dards  and  handbooks.  They  would  capture  les- 
sons-leamed  and  identify  manufacturing  tech¬ 
nology  needs.  Such  a  team  would  also  be  in  a 
good  position  to  aid  in  the  transition  of  proven  or 
emerging  manufacturing  technology.  They 
would  assist  integrated  product  teams  in  apply¬ 
ing  the  available  tools  and  techniques  to  address 
producibility  as  an  integral  part  of  design  and 
development.  They  would  devote  the  necessary 
time  to  problem  solving  in  their  specialized  area, 
with  corrective  action  feedback  to  improve  fu¬ 
ture  design  or  manufacturing  techniques.  The 
intent  of  such  integrated  functional  team  effort 
on  the  part  of  the  Government  activity  is  to  be 
more  effective  in  the  role  of  technical  consultant 
and  advisor  to  the  industry. 

7.2  Human  Resource  Development  and 
Culture  Change 

The  multidisciplined  IPDTs  create  the  need 
for:  (1)  development  of  technically  qualified 
people,  (2)  transforming  of  functional  players 


into  team  players,  and  (3)  culture  changes  in 
regards  to  delegation  of  authority  and  accep¬ 
tance  of  responsibilities.  Team  members  need  to 
be  familiar  with  both  the  product  and  its  manu¬ 
facturing,  training  and  support  process  develop¬ 
ment  and  the  evolving  supporting  computer 
technologies.  Systematic  training  and/or  job 
rotation  programs  will  be  required  to  develop 
the  proper  resources.  A  primary  function  of  the 
functional  staff  (matrix  home  office)  will  be  to 
develop  the  integrated  policies  and  practices  and 
train  the  people  that  will  be  assigned  to  IPDTs. 
The  cultural  mind-set  of  the  SPO  functional 
staffs  must  continue  to  further  evolve  from  a 
functional  orientation  to  a  product  oriented  fo¬ 
cus  in  support  of  the  SPO  Director  and  IPDTs. 
Also,  human  resource  development  will  be  re¬ 
quired  to  train  functional  players  to  perform 
even  broader  integration  roles  within  the  SPO, 
with  the  contractor  and  with  the  user,  logistics 
and  training  communities.  This  must  be  sup¬ 
ported  by  top  management’s  willingness  to 
change  by  delegating  authority  and  assigning  re¬ 
sponsibility  to  the  team  members  and  by  creat¬ 
ing  an  environment  of  trust  and  cooperation. 

Once  teams  are  formed,  all  team  members 
should  receive  training  in  Integrated  Product 
Development  principles  and  team  effectiveness 
techniques. 

7.3  Facilities 

There  is  tendency  to  locate  personnel  by 
function  which  encourages  functional  orienta¬ 
tion  to  problem  solving  and  presents  a  signifi¬ 
cant  barrier  to  continued  communications.  The 
integrated  productdevelopment  process  requires 
maximum  communications  both  within  the  team 
and  with  internal  and  external  customers.  Where 
appropriate,  physical  collocation  and  use  of 
enhanced  electronic  communications  should  be 
used.  Adequate  facilities  for  team  meetings  is 
also  a  requirement. 
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8.0  INTEGRATED  BUSINESS  REQUIRE¬ 
MENTS 

There  are  a  number  of  considerations  within 
the  integrated  product  development  process 
which  affect  our  current  business  requirements 
and  contracting  methods.  Key  processes  that 
need  to  support  IPD  are  as  follows. 

8.1  Request  for  Proposals  (RFPs).  Industry 
often  organizes  in  a  like  manner  to  its  cus¬ 
tomer — the  program  office.  Industry  claims 
they  must  do  this  to  communicate  and  respond 
effectively  to  the  functional  tasking  and  its  cor¬ 
responding  budget.  Industry  is  asked  to  go  one- 
on-one  with  their  government  counterparts  and 
proposals  and  plans  are  judged  on  how  the  con¬ 
tractor  organizes  to  achieve  this  interface.  Data 
items  are  discipline  oriented  and  similar  data 
must  usually  be  reformatted  for  different  gov¬ 
ernment  groups.  This  discipline  approach  to 
review  and/or  approval  of  data  has  led  to  the 
accusation  by  industry  that  the  functional  disci¬ 
plines  are  micromanaging  the  process  rather 
than  allowing  contractor  creativity  in  design. 
RFPs  that  request  contractors  to  propose  based 
on  functional  requirements  send  the  message  to 
industry  that  we  want  a  functional  proposal  and 
implementation  approaches  as  opposed  to  a  truly 
integrated  product  development  approach.  In¬ 
dustry  has  stated  that  changing  the  contractual 
requirements  and  interfaces  is  an  important 
facilitator  in  helping  industry  to  change.  Evalu¬ 
ation  criteria  and  Instructions  to  Offerors  must 
also  be  structured  to  encourage  a  truly  integrated 
proposal  and  contract. 

8.2  Source  Selection.  Evaluation  criteria  and 
source  selection  evaluation  teams  must  be  struc¬ 
tured  to  evaluate  integrated  proposals  and  pro¬ 
posed  contractual  documents.  The  Source  Se¬ 
lection  process  must  be  structured  to  recognize 
the  offeror’s  unique  proposal  and  the  offeror’s 
capability  to  execute  the  proposed  contract.  The 


offeror’s  technical  approaches  may  be  influ¬ 
enced  by  the  supporting  computer  technologies 
that  must  be  understood  by  the  evaluation  team. 
For  example,  an  offeror  may  propose  to  use 
computer  mock-up  in  place  of  hard  mockups. 
The  unique  offeror’s  capabilities  must  be  under¬ 
stood  in  order  to  evaluate  the  proposed  technical 
tasks  and  schedules.  Most-probable  cost  esti¬ 
mates  based  on  historical  data  may  have  ques¬ 
tionable  relevance  to  proposals  based  on  a  re¬ 
vised  development  approach  using  integrated 
product  development.  The  use  multifunctional 
teams,  product-oriented  work  breakdown  struc¬ 
tures  and  advanced  computer  technology  can 
significantly  impact  the  timing  of  activities  and 
the  nature  of  tasks  to  be  accomplished. 

8.3  Work  Breakdown  Structures  (WBS). 
The  WBS  must  be  carefully  structured  to  sup¬ 
port  the  integrated  product  team  concept.  The 
use  of  empowered  multifunctional  teams  to 
develop  the  product  and  its  manufacturing, 
support  and  training  capability  requires  that  this 
work  effort  and  its  associated  budget  be  as¬ 
signed  to  the  team  and  not  to  the  contractor's 
functional  organizations.  This  requires  a  com¬ 
plete  definition  of  the  product-oriented  WBS 
element  definitions  and  the  ability  to  tie  any 
nonproduct  oriented  WBS  elements  to  product 
WBS  elements  at  the  appropriate  tier  of  the 
specification  tree.  For  example,  system  level 
tests  would  be  tied  to  the  system  specification 
and  the  supporting  system  level  WBS  element, 
where  as,  subsystem  level  tests  will  be  tied  to  the 
applicable  subsystem  level  specification  and 
supporting  subsystem  level  WBS  element.  This 
change  is  envisioned  to  significantly  change 
current  practices  but  can  be  accomplished  within 
current  policy  and  C/SCSC  system  requirements. 

8.4  Funding  Profiles  and  Progress  Payment 
Schedules.  The  integrated  product  develop¬ 
ment  process  requires  multifunctional  involve- 
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ment  early  in  the  process  thus  skewing  the  tradi¬ 
tional  funding  profile  by  greater  up-front  load¬ 
ing  of  costs.  The  total  program  budget  should  be 
less  but  the  funding  profile  will  be  different. 
Funding  must  be  made  available  for  inclusion  of 
all  necessary  disciplines  early  in  the  design 
process.  Today’s  aeronautical  equipment  de¬ 
velopment  is  requiring  manufacturing  process 
inventions  and  development  that  are  often  more 
technically  challenging  than  the  product  design. 
Appreciation  for  this  fact  and  its  impact  on 
program  schedules  and  cost  must  be  considered. 
Progress  payment  schedules  need  to  be  tied  in 
the  integrated  product  development  process  to 
the  revised  products  produced  by  this  process. 
For  example,  tying  progress  payment  schedules 
to  engineering  release,  etc.  are  no  longer  valid 
since  engineering  releases  are  being  replaced  by 
incremental  releases  of  total  product  definition 
data.  This  product  definition  data  may  be  paper 
or  electronic  digital  data  representing  a  concep¬ 
tual  layout,  an  assembly  layout,  a  total  Build- 
To-Package  or  a  Support  Package.  Progress 
payment  schedules  should  be  linked  to  the  Sys¬ 
tem/Subsystem  Integrated  Master  Schedules  and 
the  Technical  Review  and  Audit  Process. 


8.5  Incentives  and  Award  Fees.  Incentive  and 
award  fees  must  be  carefully  structured  to  incen- 
tivize  the  objectives  of  integrated  product  devel¬ 
opment.  As  such,  they  must  be  structured  to 
incentivize  the  quality  of  the  development  proc¬ 
ess.  Successful  accomplishment  of  events  tied 
to  the  revised  development  process  should  be 
given  more  weight  than  meeting  a  calendar 
schedule. 


8.6  Long-Term  Supplier  Relationships. 

Industry  is  learning  that  long-term  supplier 
relationships  are  a  win-win  situation,  providing 
stability  for  both  partners  in  the  relationship. 
Short-term  agreements  that  are  repetitively 


competed  pressure  the  supplier  to  make  all  his 
money  on  a  new  year  contract  and  force  the 
prime  contractor  to  adjust  to  working  with  a 
succession  of  different  suppliers.  Long-term 
agreements  tend  to  merge  the  prime  contractor 
and  supplier  as  a  team  with  a  common  goal, 
rather  than  as  competitors  trying  for  short-term 
economic  advantages.  They  provide  the  sup¬ 
plier  with  an  incentive  to  maintain  quality,  as 
well  as  the  stability  required  to  expand  facilities 
to  meet  the  demand.  In  some  cases,  contracts 
that  stretch  further  out  also  force  the  supplier  to 
share  the  risk/benefit  of  changes  in  production 
rates.  The  long-term  approach  also  would  seem 
to  make  it  more  difficult  for  new  suppliers  to 
come  on  line,  but  this  does  not  appear  to  be  the 
case  based  on  industry  experience.  In  fact,  they 
have  reported  that  competition  has  become  more 
aggressive  with  many  new  companies  entering 
the  business  and  others  expanding  into  new 
areas. 

The  commercial  airframe  manufacturers  also 
are  learning  the  value  of  staying  in  close  touch 
with  their  key  suppliers.  For  example,  Boeing 
has  a  well-organized  team  that  constantly  is 
taking  the  pulse  of  key  suppliers  and  dispatches 
a  task  force  to  help  when  one  gets  into  trouble. 
Under  Douglas’  new  approach,  they  furnish  the 
supplier  with  its  business  projection  and  strate¬ 
gies  and  provides  technical  assistance  when  a 
company  hits  a  snag  rather  than  switching  to  a 
new  supplier.  Also,  contracts  do  not  necessarily 
go  to  the  lowest  bidder,  rather,  they  are  awarded 
on  a  combination  of  quality,  schedule  and  cost. 

Industry  experience  with  long-term  supplier 
relationships  has  resulted  in  more  predictable 
level  of  quality  and  on-schedule  delivery,  while 
reducing  administrative  costs  associated  with 
re-quoting  and  re-sourcing  work.  Getting  qual¬ 
ity  parts  on  schedule  has  significantly  improved 
the  efficiency  of  the  prime  contractors  opera¬ 
tions.  Subcontractors  and  suppliers  are  commit¬ 
ting  to  provide  a  competitive  price  and  are  be- 
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coming  more  efficient  in  producing  equipment 
parts  and  materials.  Subcontractors  are  enjoy¬ 
ing  their  new  partnership  role  of  becoming  more 
involved  in  the  design  of  the  parts  to  maximize 
production  efficiency. 

Integrated  product  development  encourages 
contractors  to  understand  their  supplier  capa¬ 
bilities  and  bring  their  expertise  to  the  develop¬ 
ment  process  as  early  as  possible.  As  such, 
contractors  must  select  their  suppliers  prior  to 
having  a  design  or  specification.  Knowing  a 
supplier’s  capability  requires  considerable  ef¬ 
fort  and  mutual  trust.  Industry  has  been  the  most 
successful  in  accomplishing  this  by  minimizing 
the  number  of  suppliers  and  establishing  long¬ 
term  supplier  relationships  with  proven  quality 
suppliers.  Manufacturing  initiatives  such  as 
just-in-time,  also  significantly  impact  contrac¬ 
tor/supplier  relationships. 

Integrated  business  requirements  should 
address  competition  and  breakout  policies, 
multiyear  contracts  and  “best  value”  contracting 
approaches.  Competition  and  breakout  policies 
must  be  prudently  tailored  to  each  acquisition  so 
as  not  to  be  a  barrier  and  disincentive  to  industry 
on  establishing  long-term  supplier  relationships 
while  fostering  industrial  base  development. 
Establishing  long-term  supplier  relationships  and 
resource  commitments  can  be  significantly  fa¬ 
cilitated  through  multi-year  contracts.  Con¬ 
tracts  and  contract  administrative  practices  need 
to  encourage  the  use  of  ‘best  value”  contracting 
rather  than  lowest  price. 


accounting  standards  that  allocate  indirect  costs 
do  not  provide  this  visibility  and  may  be  the 
source  of  cost  data  that  can  lead  to  bad  decisions. 
For  example,  a  product  that  has  been  “improved” 
will  not  reflect  the  true  cost  of  that  product. 
Industry  has  reported  that  they  have  made  “bad” 
make  or  buy  decisions  as  a  result  of  the  lack  of 
visibility  into  true  costs.  The  extensive  use  of 
computer  technology  to  accomplish  design  lay¬ 
outs,  design  analysis,  electronic/computer 
mockup,  computer  integrated  manufacturing  and 
computer  integrated  support  activities  and  simu¬ 
lation  are  all  contributing  to  need  for  Activity 
Based  Costing. 

8.8  Cost-Based  Profit.  Cost-based  profit 
creates  a  negative  incentive  for  industry  to 
improve  his  products  and  processes  after  con¬ 
tract  award.  Strategies  that  minimize  this  impact 
need  to  be  investigated  and  implemented.  The 
proper  application  of  activity-based  costing  and 
work  measurement  techniques  can  improve 
visibility  into  true  work  content  and  avoid  per¬ 
petuating  past  inefficiencies  through  cost-based 
pricing. 


8.7  Activity-Based  Costing.  Integrated  prod¬ 
uct  development  and  the  practice  of  continuous 
improvement  requires  visibility  into  “real  costs” 
at  the  product/process  level.  A  product  cost 
today  is  often  driven  by  indirect  costs  that  is 
often  over  50%  of  the  total  costs.  Visibility  into 
these  costs  is  essential  to  identify  major  ele¬ 
ments  of  potential  non-value  added  costs.  Cost 
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9.0  TECHNOLOGY  TRANSITION 

The  concept  of  Integrated  Product  Develop¬ 
ment  can  be  applied  both  to  the  weapon  system 
development  process  and  to  the  technology, 
prototype  and  manufacturing  process  develop¬ 
ments  which  enable  weapon  system  advance¬ 
ments.  This  includes  WRDC  advanced  devel¬ 
opment  (6.3A)  and  Manufacturing  Technology 
(7.8)  projects,  and  related  contractor  CRAD  and 
IR&D  efforts.  To  achieve  this  objective,  proc¬ 
ess  development  technology  must  be  considered 
and  funded  in  a  balanced  manner  with  product 
technology.  If  this  balance  can  be  attained,  the 
opportunity  exists  to  greatly  improve  the  flow  of 
WRDC  and  related  contractor  product  and  proc¬ 
ess  technology  to  ASD.  Four  major  opportunity 
areas  have  been  identified. 

The  first  opportunity  deals  with  the  initiation 
of  strategic  planning  for  manufacturing  proc¬ 
esses  as  early  as  possible  in  weapon  system 
concept  development.  Within  the  ASD/XR 
planning  process  for  future  weapon  systems, 
and  particularly  as  future  advanced  product 
technology  requirements  are  identified,  bal¬ 
anced  consideration  should  be  given  to  identify¬ 
ing  requirements  for  manufacturing  technology 
development  and  the  industrial  base  required  to 
create,  manufacture  and  support  these  advanced 
product  technology  features.  Also,  in  order  to 
better  support  the  XR  planning  function,  im¬ 
provements  in  the  interface  with  WRDC  must  be 
established  to  enable  early  identification  of 
requirements  and  subsequent  program  plans  for 
both  WRDC  product  and  process  technology 
and  manufacturing  technology. 

A  second  major  area  of  opportunity  is  an 
enhanced  approach  to  integrating  WRDC  prod¬ 
uct  and  process  technologies  into  ASD  weapon 
system  acquisitions.  To  realize  improvements 
in  this  area  requires:  (1)  Identification  of  ASD 
product  and  process  requirements  to  WRDC  on 
a  timely  basis,  (2)  A  balanced  focus  on  product 


and  process  development  in  WRDC  (6.3A) 
advanced  development  projects  (including  joint 
projects  between  MANTECH  and  6.3A  advanced 
development),  and,  (3)  Improved  interaction  be¬ 
tween  WRDC  and  ASD,  particularly  during  the 
early  phases  of  an  ASD/XR  concept  develop¬ 
ment. 

A  third  major  area  of  opportunity  involves 
complete  technology  transition  criteria.  Included 
in  this  area  are  metrics  for  cost,  quality,  and 
producibility  and  supportability  considerations 
as  a  big  part  of  the  SENTAR  process. 

A  fourth  opportunity  area  involves  integrated 
ASD  and  contractor  planning  for  CRAP/IR&D 
to  include  both  product  and  process  develop¬ 
ment.  This  area  deals  with  the  fact  that  most 
CRAD  and  IR&D  projects  focus  on  product 
technology  (unless  the  CRAD  project  is  funded 
by  MANTECH).  A  balance  between  product 
and  process  developments  in  advanced  technol¬ 
ogy  projects  should  be  sought  by  focusing  more 
on  the  process  requirements/developments  and 
manufacturing  technology  developments  re¬ 
quired  to  implement  product  technology  ad¬ 
vancements.  Overall,  closer  coupling  between 
future  Government  weapon  system  requirements, 
contractor  business  objectives,  weapon  system 
technology  requirements  and  product  and  proc¬ 
ess  developments  can  greatly  enhance  the  pay¬ 
off  from  the  R&D  world.  AFLC  modification 
requirements  and  repair  technology  develop¬ 
ments  must  also  be  considered. 
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APPENDIX  A 


LIST  OF  ACRONYMS 


3D/2D 

AFGS 

AFLC 

AFSCs 

AL 

ALC 

ALD 

ALH 

ASD 

ASIP 

AVIP 

C/SCSC 

CA 

CAD 

CALS 

CIs 

CITIS 

CPT 

CRAD 

tyv 

DB2 

DOD 

DT&E 

HN 

EN(PA) 

ENM 

ENSIP 

GD/FWD 

GEAE 

IBM 

ILS 

IOT&E 

IPD 

IPDT 

IPT 

IR&D 

IWSDB 

LCC 


Three  Dimensional/Two  Dimensional 

Air  Force  Guide  Specification 

Air  Force  Logistics  Command 

Air  Force  Speciality  Codes 

Deputy  Chief  of  Staff  for  Acquisition  Logistics 

Air  Logistics  Center 

Acquisition  Logistics  Division 

Directorate  of  Manpower,  Personnel  and  Training 

Aeronautical  Systems  Division 

Aircraft  Structural  Integrity  Program 

Avionics/Electronics  Integrity  Program 

Cost/Schedule  Control  System  Criteria 

Assistant  to  the  Commander 

Computer-Aided  Design 

Computer-Aided  Acquisition  and  Logistics  Support 
Configuration  Items 

Contractor  Integrated  Technical  Information  Service 

Critical  Process  Team 

Contracted  Research  and  Development 

Demonstration/Validation 

Data  Base  2 

Department  of  Defense 

Development  Test  and  Evaluation 

Deputy  Chief  of  Staff  for  Integrated  Engineering  and  Technical  Management 

Assistant  for  Product  Assurance 

Directorate  of  Manufacturing  and  Quality 

Engine  Structural  Integrity  Program 

General  Dynamics  Fort  Worth  Division 

General  Electric  Aircraft  Engines 

International  Business  Machines 

Integrated  Logistics  Support 

Initial  Operational  Test  and  Evaluation 

Integrated  Product  Development 

Integrated  Product  Development  Teams 

Integrated  Product  Team 

Independent  Research  and  Development 

Integrated  Weapon  System  Data  Base 

Life  Cycle  Cost 
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LIST  OF  ACRONYMS  (Concluded) 


LRIP 

Low  Rate  Initial  Production 

MANTECH 

Manufacturing  Technology 

MECSIP 

Mechanical  Equipment  and  Subsystem  Integrity  Program 

MIL 

Military 

ML 

Manufacturing  Technology  Directorate 

MME 

Deputy  Chief  of  Staff  for  Materiel  Management  Engineering  Division 

NAE 

National  Aerospace  Plane  Joint  Program  Office  Director  of  Engine 

NSIA 

National  Security  Industrial  Association 

PC 

Personal  Computer 

PHS&T 

Packaging,  Handling,  Storage  and  Transportation 

PK 

Deputy  Chief  of  Staff  for  Contracting 

QFD 

Quality  Function  Deployment 

R&M 

Reliability  and  Maintainability 

RAMCAD 

Reliability  and  Maintainability  Computer-Aided  Design 

REPTECH 

Repair  Technology 

RFP 

Request  for  Proposal 

SDD 

Systems  Program  Office  Directorate  of  Manufacturing  and  Quality 

SDIP 

Software  Development  Integrity  Program 

SEMS 

Systems  Engineering  Master  Schedule 

SIMS 

System/Subsystem  Integrated  Master  Schedule 

SOW 

Statement  of  Work 

SPO 

System  Program  Office 

TQ 

Total  Quality 

TX 

Technology  Exploitation  Directorate 

TXT 

Technology  Transition  Division 

WBS 

Work  Breakdown  Structure 

WRDC 

Wright  Research  and  Development  Center 

XR 

Deputy  Chief  of  Staff  for  Development  Planning 

Funding 

* 

6.3 

Advanced  Development 

6.4 

Engineering  Development 

7.8 

Industrial  Base 

I 
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